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

Hi Mark,

On Thu, Jul 17, 2014 at 03:40:07PM +1000, Mark Nottingham 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.

I must say I don't have a strong preference. I dislike 1xx but at the
same time they exist and I suspect that a 2->1 gateway will be a bit
harder to implement without them. On the other hand, 2.0 agents which
don't need them will have to gracefully deal with them if we keep them.
Everything goes down to whether these codes have real semantics or are
just for framing. IMHO Julian tends to have a good flair on semantics
related issues and I would not be very surprized if we finally came up
with a concrete example of valid use that is not transposable in 2.0.
If either solution does not work over two protocol conversions, then
we should keep the other one :

   1.1 client ----> 1-2 proxy ------------> 2-1 gateway ---> 1.1 server
   2.0 client ----> 2-1 proxy ------------> 1-2 gateway ---> 2.0 server

The first case may break WS clients if the 1-2 proxy does not have other
option than forwarding in 2.0. It may also prove not very convenient to
handle certain expect failures between the client and the server. But
that's just a feeling.

Hoping this brings some fuel to the discussion.

Willy

Received on Thursday, 17 July 2014 13:26:26 UTC