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

In message <5A94A672-277E-4F4B-AECA-12DBF0FB36A2@mnot.net>, Mark Nottingham writes:

><https://github.com/http2/http2-spec/issues/535>
>
>So far, we've had two proposals for this issue;

I buy the argument that there are valid cases for what 100-Continue
does in HTTP/1:  "I'll only send the body when you tell me to."

It's not obvious to me that 100-Continue is the best way to implement
this, since we could actually improve the way it works over the
rather arbitrary HTTP/1 semantics.

We could get the same effect, much more rigidly defined, with a
single bit on HEADERS which means "I won't send the entity body
until you tell me to."  The "tell me to" bit can be done any number
of trival ways, down to ".. until you send me a WINDOW_UPDATE on
this stream".

That seems far preferable to me.


That leaves 101 for Upgrade: and I'm not sure I see the need for
that at all.

I propose that we declare that HTTP/2 can only be "upgraded" to
protocols which retain it's framing layer.  Given that HTTP/2 is
arrived at via either Upgrade: or TLS negotiation, any protocol
that does not share HTTP/2's framing layer would be better of not
taking the detour over HTTP/2 in the first place.

Doing that, a SETTINGS can tell which protocols are supported
at the receiver, and by giving these protocols half-open frames
different from HEADERS and PUSH-PROMISE, these protocols can
run in parallel with HTTP/2, rather than as replacements for it.

That means we don't need 101 either.

That also seems far preferable to me.

So this is my position:

I'm against supporting 1xx responses the way HTTP/1 does.

I'm for adding the functionaly they offer in way that makes
HTTP/2 a better protocol.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Thursday, 17 July 2014 12:28:21 UTC