3 ms·
I don't understand the problem. If there's something wrong with the request, why expect a different response if the same request is sent again?
by sp332 7y ago
I don't understand the problem. If there's something wrong with the request, why expect a different response if the same request is sent again?
- Karunamon 7y agoThe error could be (and I'd say, usually is) transient, i.e you hit a page and something is broken, you reload and then it's fixed. Real-life example I'm familiar with: Content being served from a busy NAS that buckled under load. You'll have some requests time out with 504s, some return 500s, some that make the files appear missing and so you get 404s. I know, braindead design that shouldn't happen, but it does happen.
- cestith 7y agoThey're caching the resource based on URI only or on HTTP method and URI only is the problem. If you're caching 400 (which many people have noted is against the RFC and can be troublesome) then you need to make sure you're only caching it for a matching request. If I send a poisoned header and you cache a 400 for my full request including that poisoned header, then that's one thing. If I send a poisoned header and you cache a 400 for all accesses to that URI whether or not they include the header that caused it to be a bad request, that's vulnerable to this BS.