- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Thu, 28 Jul 2016 10:07:39 -0600
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Adrien de Croy <adrien@qbik.com>
On 07/28/2016 01:00 AM, Julian Reschke wrote: > On 2016-07-28 01:26, Alex Rousskov wrote: >> On 07/27/2016 03:37 PM, Julian Reschke wrote: >>> On 2016-07-27 22:56, Adrien de Croy wrote: >>>> maybe need something like >>>> >>>> Vary: Request-Body >> >> >>> I'd say this is implied anyway. >> >> >> RFC 7231 appears to imply the opposite: It explicitly allows GET >> requests with bodies while not placing any request-body-related >> restrictions on their response cachability and sharing AFAICT. > I don't see how this means that you could ignore the body should you > decide to cache it. What is not prohibited is allowed. If caching a GET response while paying no attention to the GET request body is not prohibited, then it is allowed. If it is allowed, then "Vary: Request-Body" is not implied in the GET transaction context. >> Similarly, there are instructions for caching POST responses that do not >> mention request body importance (and nearly implying its irrelevance by >> mentioning GET hits for POST-cached responses). > So these are two distinct things; the POST itself could be cacheable > *and* the POST response can be decorated to imply that it can be used > for subsequent GET requests. I am talking about the latter. The explicit and detailed instructions on how to make a POST response cachable do not say anything about variance on the POST request body. Thus, "Vary: Request-Body" is not implied in a POST transaction context. We can all join in a happy hand-waving exercise while talking about "intent", "practice", and blocking valid messages we dislike, but until somebody finds a _protocol_ requirement that clearly implies "Vary: Request-Body", there is no such implication. Alex.
Received on Thursday, 28 July 2016 16:08:23 UTC