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

Re: 1xx response semantics

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 6 Jul 2011 01:03:51 +0200
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, httpbis Group <ietf-http-wg@w3.org>
Message-ID: <20110705230351.GD18576@1wt.eu>
On Tue, Jul 05, 2011 at 11:37:08AM -0700, Roy T. Fielding 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.

OK for seeing it like this, but from an HTTP point of view it's final,
as there is no HTTP after the Upgrade. The server's response might
very well be that it's waiting for the client to send its request
(eg: TLS upgrade).

You way of describing it is very interesting in my opinion, because it
could be the solution to explain in the spec why it's in the 1xx codes
and why it's still final for HTTP.

Received on Tuesday, 5 July 2011 23:04:20 UTC

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