Comment by ralferoo
7 hours ago
Maybe my knowledge is out of date in terms of how people generally use POST nowadays, but AFAIK multipart/form-data is still the most common encoding for data and occasionally application/x-www-form-urlencoded.
Both of these, the key values can be in any order with the same interpretation. That's kind of a moot point for POST method, because they should never be cached anyway, but for the new QUERY method it'd be reasonable to expect a cache hit whenever the parameters are the same regardless of order.
My point is that for a GET, you can't assume that the order isn't important, because the URL is an opaque string by the time it hits the cache. However, POST (and now QUERY) explicitly says what the coding is, so for instance with application/x-www-form-urlencoded we can be sure that the parameters can be in any order without changing the meaning. You cannot infer that from a URL itself.
As to your point, yes you can use any other encoding you like to. But most systems don't do that, they use multipart/form-data.
This RFC does not require caching to be implemented at all, so it wouldn’t be reasonable to expect a cache hit, no. But if your implementation does that, cool :)
An RFC would never mandate caching. But the table in the article says "cacheable: yes" for GET and QUERY. There is no "my implementation" because this is a proposal that has only just been proposed and there is currently "no implementations". I'm simply saying that QUERY will be harder to get caching correct compared to GET, and I'm almost certain there will be end up being CVEs resulting from its implementation.
It’s been an IETF Internet-Draft for a few years at this point, so there are some implementations already in the wild.
What I mean is that implementations are free to choose do something as complex as what you suggest, but also something as simple as hashing the body as a blob, and they can even bail on caching completely (for example if the payload is too large).
All of those options would be correct behavior per the RFC.
Of course we may still see CVEs from this, but they will be self-inflicted, not caused by a complex standard.