Re: Expect: + Upgrade: = ...

On 6/09/2013 6:29 p.m., Willy Tarreau wrote:
> On Thu, Sep 05, 2013 at 04:19:31PM -0700, Martin Thomson wrote:
>>>>> Using both Expect: 100-continue and Upgrade, at the same time,
>>>>> will work fine -- it can be implemented as already specified.
>>>>> 100 is required to be sent first.
>>>> Reading http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23#section-6.7,
>>>> this wasn't obvious, should it be?
>>> I see no alternative in fact. Anyone in the chain may emit a 100
>>> and the client has to be prepared to drain any number it sees before
>>> a final response. 101 is not final, but it's half-way to the final
>>> one.
>> I see no alternative either, but it's probably not clear to everyone
>> that all the 100s come before the 101.
> First, nothing in the text makes this obvious (at least to me). Second,
> the usual rule applies : it was not obvious to at least one implementer,
> which is a very good reason to try to make it clearer, otherwise we're
> at risk of seeing various implementations guess differently.
>
>> It really just makes we wonder just how easily generalized the
>> handling for the 1xx series is in practice.  Maybe it's just that 101
>> has to be the last 1xx, or maybe it's that 100 has to be before any
>> others, or maybe it's just this specific pair of status codes.
> Well, it's a bit of all of this since we have only two 1xx. I'd still
> say that 100 is the first one because any unknown 1xx code has to be
> handled as 100 (by definition). So in practice nothing has to be said
> about 100, we're in the default situation. And 101 necessarily is the
> last one because we're supposed to be talking a different protocol
> just after it, whose framing is unknown to 1.1 implementations.
>
>> Either way, I would like to see it documented.  I'm happy to propose
>> text for httpbis if that helps, but I'm not sure that I'm qualified.
> 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.

So like I said 100 and 101 can occur in any order. 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?

Amos

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