- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 09 Feb 2015 08:11:04 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 2015-02-09 02:23, Mark Nottingham wrote: > On 2 Feb 2015, at 7:18 pm, Julian Reschke <julian.reschke@gmx.de> wrote: >> >> On 2015-02-02 09:07, Mark Nottingham wrote: >>> Yes, but the semantics of those headers are exactly the same in both directions. >> >> I think that's the case here, too. No? > > No. The existing, client-to-server semantic of Accept-Encoding is "For the response associated with this request, I will accept the following encodings..." > > In the server-to-client direction, the proposed semantic is "For some unbounded set of future requests, I might accept the following encodings..." I agree that there's a difference here, but I fail to see how it's critical. I could rephrase the definition to clarify that the information applies to the request it was sent with, and that future requests can have different behavior. > There are a number of subtle differences there, especially about the scope of applicability -- one of the most ill-defined areas in HTTP metadata. Anything besides the freshness issue? Best regards, Julian
Received on Monday, 9 February 2015 07:11:36 UTC