Re: RFC7234: Can a request body form part of a "cache key"?

On Thu, Jul 28, 2016 at 10:29:22AM -0700, David Morris wrote:
> 
> It is impossible for me to imagine a use case where the body associated
> with GET wouldn't have the same significance to caching as parameters
> included on the URL. Hence, I believe this is a bug in the specification
> and not a new requirement. To me this was an obvious requirement.

Given that it's clearly stated that the GET body (if any) has no defined
semantics, it doesn't make sense to expect caches to consider changes on
something with no semantics to decide whether or not to provide a response from
their cache. It's like showing someone a hand-written text using an alphabet
they don't know and saying them "turn right at the first roadsign you see
with this written on it". But the person doesn't read this alphabet, so she
doesn't know when different forms or line lengths are relevant or not and
indicate a difference or not. Here it's the same. Should your cache compare
bytes ? Should it assume %-encoding ? Should it ignore blank lines ? Should
it ignore the CR before an LF ? Should it ignore everything ? Every choice is
possible and valid until some semantics are defined, and here they are not.
At the very least you would need to define these semantics on the cache
itself before taking such a decision.

Regards,
Willy

Received on Thursday, 28 July 2016 19:37:49 UTC