- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 10 Feb 2015 11:17:09 +1100
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> On 9 Feb 2015, at 6:11 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > > 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. The difference in Cache-Control is likewise small, but it causes problems often IME. >> 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? It's also a certainty issue -- if you send Accept-Encoding as a client, the server knows it can select one of those encodings, and doesn't have to worry about failure. If the server sends it and the client uses it, the client needs to be able to recover from failure gracefully. Let's flip it around -- what does reusing A-E buy us here? Are we trying to conserve registry space or something? :) -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 10 February 2015 00:17:39 UTC