- From: Ben Campbell <ben@nostrum.com>
- Date: Thu, 03 Sep 2015 09:12:38 -0500
- To: "Julian Reschke" <julian.reschke@greenbytes.de>
- Cc: "The IESG" <iesg@ietf.org>, "Mark Nottingham" <mnot@pobox.com>, ietf-http-wg@w3.org
On 3 Sep 2015, at 3:40, Julian Reschke wrote: > On 2015-09-03 03:20, Ben Campbell wrote: >> ... >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This should be easy to resolve, but I want to make sure there's been >> thought on it: >> >> section 3 says: >> "Note that this information is specific to the associated request; >> the >> set of supported encodings might be different for other resources on >> the same server, and could change over time or depend on other >> aspects of the request (such as the request method)." >> >> .. but then later... >> >> "[...] However, the header field can also be used to indicate to >> clients >> that content >> codings are supported, to optimize future interactions. For example, >> a resource might include it in a 2xx response when the request >> payload was big enough to justify use of a compression coding, but >> the client failed do so." >> >> This seems to indicate a need for guidance on when the client can >> reuse >> the Accept-Encoding value. >> ... > > Well, it can be used with caveats mentioned in the first excerpt. The > client can try, and if the situation *has* changed it will find out. > > Note that this isn't different from other similar HTTP features, such > as the "Allow" and "Accept" header fields. Okay, based on the "allow" and "accept" bit, I will clear the discuss (but keep the comment.) I do think some explicit guidance on when it's reasonable to send or use the header would be useful. Right now it's left for the reader to infer. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> -- section 3, 5th paragraph: >> For the two SHOULDs and one SHOULD NOT in this paragraph, can you >> suggest >> some reasons an implementation of this spec might choose something >> different? > > This goes back to the discussion about whether we are changing > HTTP/1.1, or whether this is an optional extension (which it is; I > don't believe we have consensus to make a change here that would make > existing HTTP/1.1 servers non-compliant). I personally think a MUST in this draft would be expected to apply to implementers of this draft, not people who don't implement (or possibly even read) it. > > The intent of this spec is to be eventually in-lined into RFC7231bis; > as such it might make sense to actually get rid of the first two > SHOULDs. The SHOULD NOT actually can be a MUST NOT without the risk of > making any existing server non-compliant which isn't already > non-compliant. > > "Servers that fail a request due to an unsupported content coding > ought to respond with a 415 status and ought to include an > "Accept-Encoding" header field in that response, allowing clients to > distinguish between content coding related issues and media type > related issues. In order to avoid confusion with media type related > problems, servers that fail a request with a 415 status for reasons > unrelated to content codings MUST NOT include the "Accept-Encoding" > header field." Are you proposing to make that change now, or at the point of merging into RFC7231bis Thanks! Ben.
Received on Thursday, 3 September 2015 14:13:22 UTC