- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 25 Mar 2014 10:36:42 +1100
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 21 Mar 2014, at 6:01 pm, Julian Reschke <julian.reschke@gmx.de> wrote: >>>> I don't think anyone is talking about *limiting* what you can do in HTTP/2 here -- what's being discussed is whether server-side support for GZIP content-coding in requests should be *required*. >>> >>> I think it would be good if we (a) encouraged servers to do it, and (b) clarified error handling if you don't. >>> >>> 1) Define a status code for "unsupported content-encoding" (plus maybe discovery via a Accept-Encoding header field that can be sent with it) >> >> Right now this falls into 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. >> """ >> >> So, it could be a new status code (that takes "or Content-Encoding" out of the definition of 415), or it could be a header on 415 that further refines its semantics. > > Ah. I had forgotten that we added this to the description of 415. > > So if we want to go down that route, we could recommend a 415 and in addition elevate "Accept-Encoding" to a response header field that could be used with 415. That seems to make sense, but it isn't something specific to HTTP/2, and it's extending the semantics of a HTTP/1 header field. That sounds like a new spec that updates p2-semantics. Julian, do you want to sketch that out so people can have a look? Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Monday, 24 March 2014 23:36:29 UTC