W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Expect: + Upgrade: = ...

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 5 Sep 2013 16:19:31 -0700
Message-ID: <CABkgnnUhUXH4px2NcMu6JNs4ZhG=+G07m1mvAUy5Q+zq_umhBg@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC