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

Hi Mark,

On Tue, Oct 22, 2013 at 04:56:04PM +1100, Mark Nottingham wrote:
> Hi Amos,
> 
> On 15/10/2013, at 4:47 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> > 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.

Indeed in my opinion, the intent of 100-continue is more a connection-centric
despite being implemented end-to-end. But the fact that anyone in the middle
can send it proves it's not completely end-to-end. For 101 it's different
though.

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

No I really think Amos was talking about a gateway in front of a proxy.
Put haproxy in front of a squid farm for example, that's something common.
Haproxy will understand the Upgrade+101 and will obey by maintaining an
opaque tunnel between the client and the "server" (haproxy's next hop,
here one of the squid). Haproxy in the middle doesn't need to know the
upper protocol, it just knows that both sides agree on the protocol and
that all they want is to speak in this new language.

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

Indeed I fail to see the problematic case, considering that we don't need
to upgrade from 1.1 to 1.1, so the upgrade will be from 1 to 2, thus we
won't see 100 passing through anymore.

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

Probably we should consult the browser guys and suggest implementing the
same heuristics they've been using for ages on this.

Willy

Received on Tuesday, 22 October 2013 06:40:46 UTC