- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Thu, 3 Sep 2015 17:07:58 +0200
- To: Ben Campbell <ben@nostrum.com>
- Cc: The IESG <iesg@ietf.org>, Mark Nottingham <mnot@pobox.com>, ietf-http-wg@w3.org
On 2015-09-03 16:12, Ben Campbell wrote: > On 3 Sep 2015, at 3:40, Julian Reschke wrote: > ... >> 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. Yes, but we're stating that this spec updates the definition of Accept-Encoding and status 415, so it would become a normative HTTP requirement (IMHO). >> 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 I think we should make this change right now. Best regards, Julian
Received on Thursday, 3 September 2015 15:08:24 UTC