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

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Mar 2015 18:46:42 +0100

(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 <[email-masked]>
To: 	Julian Reschke <[email-masked]>

Hi Julian,

Sorry for the delay in replying.

On Sat, Jan 31, 2015 at 6:33 AM, Julian Reschke <[email-masked]
<mailto:[email-masked]>> 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.

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

Ted

     Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Mar 2015 13:31:15 +0100

> include other encodings as well.  That seems valuable, but not well

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."

> 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)

> 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