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

Re: 1xx response semantics

From: Brian Pane <brianp@brianp.net>
Date: Tue, 5 Jul 2011 12:25:43 -0700
Message-ID: <CAAbTgTtK3N=m-Hdz64ybr5xCsjXyVdZeF0AsnqHTxwgxGSO07Q@mail.gmail.com>
To: httpbis Group <ietf-http-wg@w3.org>
On Tue, Jul 5, 2011 at 11:37 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Jul 4, 2011, at 11:13 PM, Poul-Henning Kamp wrote:
>> In message <20110705051401.GB12909@1wt.eu>, Willy Tarreau writes:
>>> In fact, 101 is a final status while 100 is an intermediate one.
>> That has always bugged, me: I think 101 should have been a 2xx or 3xx
>> response.
>> Maybe simply acknowleding rather than generalizing from this mistake
>> is the best idea ?
> Oh, for crying out loud.
> 101 is an interim response.  The first response in the new protocol
> after an Upgrade is the response to the first request.  If I send an
> Upgrade to waka on an HTTP GET request, the waka server will respond
> with 101 in HTTP and then the equivalent of a 200 response in waka.
> There is no second request.  That's the whole point in including a
> zero-latency bootstrap upgrade within HTTP.

Speaking of the 101/Upgrade mechanism... it seems fundamentally
incompatible with request pipelining. If the first request in a
pipeline indicates a willingness to upgrade to some non-HTTP protocol,
and the server decides to switch to that other protocol upon receipt
of the first request, the subsequent requests already in the pipeline
may very well be syntactically invalid in the newly chosen protocol.

Should the HTTP/1.1 spec thus prohibit the use of the Upgrade header
in pipelined requests, or is the issue too obvious to document

Received on Tuesday, 5 July 2011 19:26:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC