Re: Expect: + Upgrade: = ...

Hi Amos,

On Fri, Sep 06, 2013 at 11:23:10PM +1200, Amos Jeffries wrote:
> >Well maybe start with something along these lines ?
> >
> >    http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-6.2.1
> >
> >    If a server wants to receive a request payload body before deciding to
> >    switch the protocol, it may have to send a 100-continue interim 
> >    response
> >    first, according to the rules in 6.2.1.
> >
> >    A client waiting for a 101 status code to upgrade the protocol must 
> >    still
> >    be prepared to handle other 1xx interim responses first before 
> >    receiving
> >    the 101 status code confirming the protocol upgrade.
> 
> Holdup.
> 
> There is nothing preventing the server emitting further 100 status 
> frames inHTTP/2 format.

I have absolutely no problem with this obviously and it is 100% compatible
with the text due to the word "before" in the first sentence.

> So like I said 100 and 101 can occur in any order.

This statement is confusing because it cancels any notion of HTTP version. In
1.1 we cannot have 100 after 101. However we can have a 101 in 1.1 followed
by a 100 in 2.0, just as we could have an SSH banner after a 101 switching to
any other protocol. The HTTP/1.1 protocol terminates upon 101 to switch to
another protocol. And this other protocol is free to do whatever it finds
suitable.

> There is no reason 
> for the order of them to have any effect on the transaction as a whole. 
> 101 has no effect on the *request* bytes and 100 has no effect on the 
> *response* bytes. Why are people seeing any problem here at all?

I think because they fear they'd have to send the body in 1.1 framing format
instead of 2.0 framing format or conversely depending on the order, which is
wrong. If you get a 100 in 1.1, obviously it's before the 101 upgrade (since
the interim response 101 terminates at the double CRLF which marks the switch)
so you must post the body in 1.1 framing form. If a server finds it more
appropriate to switch first then get the data in whatever other protocol it
likes, it should upgrade first then ask for the data.

I remember Roy insisting a lot on 101 being an interim response during the
work on the WebSocket spec. Here we can see how much sense it makes : the
client knows that only the protocol has switched but the request has not
yet been processed. So the client which has not posted a payload and sees
a switch might still have to post a payload if required to do so by the
next protocol rules, with it being a 100 or an implicit unconditional send.

That's why I think there is no problem at all. However it might not be
obvious to get right initially, as Daniel reported.

Regards,
Willy

Received on Friday, 6 September 2013 11:57:23 UTC