Re: draft-reschke-http-cice-latest, "3. Extensions to 'Accept-Encoding' Header Field"

On 2015-03-09 18:46, Julian Reschke wrote:
> (forwarding to the WG mailing list)
>
>
> -------- Forwarded Message --------
> Subject:     Re: draft-reschke-http-cice-latest, "3. Extensions to
> 'Accept-Encoding' Header Field"
> Date:     Thu, 5 Feb 2015 13:12:23 -0800
> From:     Ted Hardie <ted.ietf@gmail.com>
> To:     Julian Reschke <julian.reschke@gmx.de>
>
>
>
> Hi Julian,
>
> Sorry for the delay in replying.
>
> On Sat, Jan 31, 2015 at 6:33 AM, Julian Reschke <julian.reschke@gmx.de
> <mailto:julian.reschke@gmx.de>> wrote:
>
>      Hi there,
>
>      the minutes
>
> (<http://tools.ietf.org/wg/__httpbis/minutes?item=minutes-__90-httpbis.html
>
> <http://tools.ietf.org/wg/httpbis/minutes?item=minutes-90-httpbis.html>>)
>      say:
>
>                     Ted: Has concern when this might appear in other
>          places. Semantics
>                     are clearer
>                     if it comes in 4xx, confusing if in 2xx (but possibly
>          valuable). Prefers a
>                     different status code
>
>
>      Ted:
>
>      1) What exactly are your concerns with respect to use in status
>      codes other than 4xx?
>
>
> ​If this appears in a 4xx ​message, I think the usage is clear.  I think
> the document
> could explain what happens if other status codes are used.  In a 2xx,
> for example,
> I assume the accept-encoding field would have to contain whatever the
> client had just sent (or why is it a success?), but that it might
> include other encodings as well.  That seems valuable, but not well
> described.

In my latest edits I have:

"Servers that fail a request due to an unsupported content coding SHOULD 
respond with a 415 status and SHOULD 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 SHOULD NOT 
include the "Accept-Encoding" header field.

While sending "Accept-Encoding" in a 415 (Unsupported Media Type) 
response will be the most common use case, it is not restricted to this 
particular status code. For instance, a server might include it in a 2xx 
response when a request payload was big enough to justify use of a 
compression coding, but the client failed to do so."


>      2) Regarding another status code: this is not new; RFC 7231 already
>      says that 415 is applicable to unsupported content encodings
>      (<http://greenbytes.de/tech/__webdav/rfc7231.html#status.415
>      <http://greenbytes.de/tech/webdav/rfc7231.html#status.415>__>):
>
>          6.5.13 415 Unsupported Media Type
>
>          The 415 (Unsupported Media Type) status code indicates that the
>          origin server is refusing to service the request because the
>          payload is in a format not supported by this method on the
>          target resource. The format problem might be due to the
>          request's indicated Content-Type or Content-Encoding, or as a
>          result of inspecting the data directly.
>
>
>      Why do you think that a new status code is needed here?
>
>
> So, if I get a 415 and the Content-Encoding header is present ​and
> contains the Content-Encoding the client sent, then this means the
> Content-type within the encoding was not acceptable?  If that is the

(See above; I added a recommendation not to send it unless there 
actually was a content coding related problem)

> case, wouldn't a server side Accept: do the same thing for the
> Content-Type as the Content-Encoding header does here?

We could add that, but for Accept the situation would be more complex as 
the supported media types are likely depend on the request method (see, 
for instance, 
<http://greenbytes.de/tech/webdav/rfc5789.html#accept-patch>). My 
preference would be not to expand the scope to this area.

Best regards, Julian

Received on Wednesday, 11 March 2015 12:31:43 UTC