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

Hi,

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

Reading various people's use cases has finished to convince me that I'd
rather keep the 1xx semantics. The problem we have with 1xx is that in
HTTP/1.1 they are addressing both semantics and transport at the same
time. In H2, these two are much better split and pretending that the
framing will ensure their emulation is not a satisfying response especially
since framing is mostly hop-by-hop while their semantics is mostly
end-to-end. I don't care how it's implemented provided that it is not
conflated with the framing layer. We can even invent interim frames
that can be flow-controlled etc...

I think Roberto made a good point about flow control. I'm not really scared
about this given that there are rarely large headers in 1xx responses (if
any at all), but if we do the things, better do them correctly. That could
be one more reason for having a separate frame type from HEADERS, which
would basically be a flow-controlled HEADERS frame, or simply to have a
flag on the HEADERS frame to declare whether they're flow-controlled or
not (which could also help for the other cases where people used to worry
about this, but that's a different story).

So I had concerns about 1->2 and 2->1 gateway hacks without 1xx, but now
I'm pretty much convinced that we'd miss a useful HTTP/1.1 feature without
them eventhough a number of the participants here do not use them for
anything but flow-control and/or framing.

So that's A) for me.

Regards,
Willy

Received on Friday, 18 July 2014 18:11:40 UTC