- From: Brian Pane <brianp@brianp.net>
- Date: Tue, 5 Jul 2011 12:25:43 -0700
- 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 explicitly? -Brian
Received on Tuesday, 5 July 2011 19:26:30 UTC