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

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

     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

Received on Monday, 9 March 2015 17:47:10 UTC