W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Expect/Continue and Removing 1xx Final Status codes from HTTP/2

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 22 Oct 2013 16:56:04 +1100
Cc: ietf-http-wg@w3.org
Message-Id: <4C8DA491-9A40-4CD6-8DB6-03681A2C7272@mnot.net>
To: Amos Jeffries <squid3@treenet.co.nz>
Hi Amos,

On 15/10/2013, at 4:47 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 15/10/2013 5:45 p.m., Willy Tarreau wrote:
>> Hi Mark,
>> 
>> On Mon, Oct 14, 2013 at 05:43:30PM -0700, Mark Nottingham wrote:
>>> At last week's Interim in Seattle, we discussed how we'll handle Expect/Continue in HTTP/2.0.
>>> 
>>>   https://github.com/http2/http2-spec/issues/18
>>> 
>>> The plan so far has been to NOT accommodate Expect/Continue on the wire, instead requiring software that receives an Expect header before an HTTP/2.0 hop to synthesise a 100 Continue response.
>> (...)
>>> What do people think?
>> I fully support this for the exact reasons you mentionned.
> 
> The proposal is fine from a HTTP/1->HTTP/2 gateway standpoint. But there are some issues that need to be clarified before I would be happy agreeing to it...
> 
> What is the proposal for replacing Upgrade+101 status in HTTP/2 ? Some kind of yet to be defined frame?

There will be no replacement on the wire; protocol negotiation is being moved "before" HTTP/2, and so we expect the negotiation mechanisms to be useful for several versions of HTTP.

> For Upgrade we have the multiple proxy case.  Where a gateway

I think you mean "proxy" here

> is not able to perform the Upgrade itself, but is capable of switching to an opaque tunnel and forwarding bytes to some upstream which *might*. In HTTP/1-only world we passed on the request assured that the peer

you mean the upstream proxy?

> would understand it, but in the new world the upstream may not necessarily speak HTTP/1.

Why? For the foreseeable future, it'll need to.

> So what HTTP/2 feature is to be used to negotiate between two HTTP/2 peers for converting the stream to an opaque set of DATA and having the upstream perform the Upgrade?

I think you're making an argument that HTTP/2 needs something like CONNECT, not that we need Upgrade (if I understand correctly). And, maybe doing some endgame planning on how this protocol will work without HTTP/1 generally.

> What is the proposal for HTTP2->HTTP/1 gateways to save bandwidth where Expect:100-continue was previously working?
>   Do 2->1 protocol gateways always use Expect:100-continue on the HTTP/1 mapping? or are we all expected to be happy with a single HTTP/2 hop somewhere on the chain resulting in HTTP/1 backend hops being flooded with avoidable payload?

I'm inclined to specify some heuristics about payload size (where available; it usually is, thanks to most servers requiring C-L) and use of Expect: 100-continue.


> I am generally in agreement with the removal of this one provided the texts is clear that this is not a *removal* as such, but a replacement with native HTTP/2 framing flow control meeting the same need. That will help prevent the obvious requests to get it "re-added". But the above question still does have to be met or HTTP/2 will be casuing more damage than broken HTTP/1 support already is.

Agreed.

Cheers,

--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 22 October 2013 05:56:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC