- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 5 Sep 2013 16:19:31 -0700
- To: Willy Tarreau <w@1wt.eu>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Michael Sweet <msweet@apple.com>, Daniel Stenberg <daniel@haxx.se>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On 5 September 2013 15:15, Willy Tarreau <w@1wt.eu> wrote: > On Thu, Sep 05, 2013 at 01:30:31PM -0700, Martin Thomson wrote: >> On 5 September 2013 11:17, Roy T. Fielding <fielding@gbiv.com> 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. 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. 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.
Received on Thursday, 5 September 2013 23:19:59 UTC