Re: Getting to Consensus on 1xx Status Codes (#535)

Mark,

I support *both* proposals, with B deprecating *new* 1xx status codes.  See below...

On Jul 17, 2014, at 1:40 AM, Mark Nottingham <mnot@mnot.net> wrote:
> <https://github.com/http2/http2-spec/issues/535>
> 
> So far, we've had two proposals for this issue;
> 
> a) Accommodating non-final responses in HTTP/2
>   See Julian's proposal at <https://gist.github.com/reschke/48ec30b0ac9d012b8b4e> for an idea of how this would look in the spec.
> 
> b) Publishing a separate document deprecating 1xx status codes
>   Thereby preventing the establishment of new ones (HTTP/2 already defines how to deal with 100, and 101 is not relevant to this protocol. 102 was dropped by its primary use case, WebDAV, here: <http://tools.ietf.org/html/rfc4918#appendix-F.3>)
> 
> I'd like to hear:
> 
> 1) Your preferred outcome (if any)
> 2) Whether you can live with the other option, and if not, why
> 
> "I have no preference" is useful information too.
> 
> If you indicate you can't live with one (or both) of the options, you MUST give a detailed, relevant reason as to why; omitting the reason means your "can't live with" will be ignored.

I originally believed that supporting Expect: 100-continue and 100 responses in HTTP/2 was unnecessary, and have expressed that opinion to the list on several occasions in the past.  The main use of 100-continue is to provide a relatively safe, early abort of POST and PUT requests, and IPP uses this extensively to prevent the needless transmission of gigabytes of print data when a Print-Job request requires authentication.  In HTTP/2, the framing layer provides a suitable alternative where the server can reset the stream used for the POST or PUT request - in effect, we have a "stop, don't send more" signal in HTTP/2 vs. a "go ahead" signal in HTTP/1.1.  Both happen to work for IPP over HTTP/2, but semantically they are different.

Recent discussions of supporting HTTP/1.1 to HTTP/2 proxies/gateways has highlighted this semantic difference, and it does sound like bridging HTTP/1.1 Expect semantics to HTTP/2 will be basically impossible without serious use of duct tape and fair amount of luck.  So I support Julian's proposal (option A) to add non-final response HEADER frames to HTTP/2.

Regarding option B:

- We should only deprecate *new* 1xx status codes.
- We should formally deprecate 102 - 4918's mention of it being removed in an appendix isn't particularly visible. We can reference RFC 4918 for the deprecation but we should actually remove 102 from the registry (or mark it as deprecated).
- For 100 status codes, we can clarify that they must only be sent by a HTTP server if the client includes the Expect: 100-continue header in its request.  Thus, the client (application) is stating its ability to handle non-final responses by requesting the non-final response behavior.
- We can also provide interoperability recommendations for 100-continue: clients SHOULD NOT wait indefinitely for a 100 response before sending the request message body.
- I believe that the HTTP/2 document addresses status code 101 sufficiently for HTTP/2.  Perhaps the B document can reference HTTP/2 so that it is clear that 101 is only for HTTP/1.x.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair