Re: Expect: + Upgrade: = ...

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.

Regards,
Willy

Received on Friday, 6 September 2013 06:31:14 UTC