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

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?

For Upgrade we have the multiple proxy case.  Where a gateway 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 would 
understand it, but in the new world the upstream may not necessarily 
speak HTTP/1.
  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?


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

Amos

Received on Tuesday, 15 October 2013 05:47:34 UTC