Hacker News new | ask | show | jobs
by CodesInChaos 4 days ago
The browser can simply store a collision resistant hash (e.g. SHA-256) of the body, if it wants a smaller cache key. I can't really think of any caching related attacks that don't equally apply to a query parameter. Generating a unique 30 character query parameter is just as easy as generating a 30 MB request body, if you want to flood the cache.
1 comments
ralferoo 4 days ago
Not necessarily that simple, as you'd have sort all the input parameters to maintain a useable cache key. Not especially difficult, but if the data is large and so re-allocation and sorting is required, then you're starting to open up the attack surface where bugs might have been introduced.
link
dagss 3 days ago
Do you have to? Is it common to treat ?a=1&b=2 the same as ?b=2&a=1 in browser/CDNs/etc?

Seems the spec puts this as a MAY. I think I doubt it will be implemented in generic ways, except perhaps for urlencoded payloads. After all you cannot normalize in general without knowing the query language. At the backend it does not matter, may as well cache one level deeper based on the parsed input irrespective of QUERY or not.

link
ralferoo 3 days ago
No, that was my point. In a GET request, a caching proxy cannot assume the URL is URL encoded parameters, because the URL can contain data encoded in any form. So, you could only cache a GET on an exact URL.

But for a QUERY that explicitly marked the data as multipart or url-encoded, then semantically the order of parameters no longer matters.

That said, it's hypothetical because the only thing that uses those at the moment is POST and that explicitly should never be cached.

But there's another reply above to my comment that points out that a caching implementation is free to do what it likes, and if it fails to cache when parameters are in a different order, then it would still be correct, which is a fair point. That comment was https://news.ycombinator.com/item?id=48578024

link
CodesInChaos 3 days ago
I think the only sane approach for caching comparing if the body is identical and not apply any content type specific transformations. It's the safest choice, and the cache not being effective in some edge cases isn't a big deal. The client can always canonicalize the data itself, if it matters for its use-case.

Even if the spec says that different representations are equivalent, it's quite common for applications to treat them differently. For example field ordering in json objects is supposed to not matter, but some serializers care if a type discriminator is the first field.

link