Re: 1xx response semantics

Brian Pane <brianp@brianp.net> Tue, 05 July 2011 19:27 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8CF21F8931 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 5 Jul 2011 12:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.977
X-Spam-Level:
X-Spam-Status: No, score=-9.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmWfRNqG30Ys for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 5 Jul 2011 12:27:10 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6C64021F8A18 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 5 Jul 2011 12:27:10 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1QeBGW-0002O9-VT for ietf-http-wg-dist@listhub.w3.org; Tue, 05 Jul 2011 19:26:36 +0000
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <brianp@brianp.net>) id 1QeBGQ-0002NL-CS for ietf-http-wg@listhub.w3.org; Tue, 05 Jul 2011 19:26:30 +0000
Received: from mail-vw0-f43.google.com ([209.85.212.43]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <brianp@brianp.net>) id 1QeBGO-0000xp-VE for ietf-http-wg@w3.org; Tue, 05 Jul 2011 19:26:30 +0000
Received: by vws10 with SMTP id 10so5724643vws.2 for <ietf-http-wg@w3.org>; Tue, 05 Jul 2011 12:26:03 -0700 (PDT)
Received: by 10.220.7.82 with SMTP id c18mr2330419vcc.45.1309893963152; Tue, 05 Jul 2011 12:26:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.191.77 with HTTP; Tue, 5 Jul 2011 12:25:43 -0700 (PDT)
X-Originating-IP: [216.243.35.32]
In-Reply-To: <CAE9FF05-4339-42E4-BC21-9CC0A63CF58C@gbiv.com>
References: <13323.1309846383@critter.freebsd.dk> <CAE9FF05-4339-42E4-BC21-9CC0A63CF58C@gbiv.com>
From: Brian Pane <brianp@brianp.net>
Date: Tue, 05 Jul 2011 12:25:43 -0700
Message-ID: <CAAbTgTtK3N=m-Hdz64ybr5xCsjXyVdZeF0AsnqHTxwgxGSO07Q@mail.gmail.com>
To: httpbis Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Received-SPF: none client-ip=209.85.212.43; envelope-from=brianp@brianp.net; helo=mail-vw0-f43.google.com
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7
X-W3C-Scan-Sig: lisa.w3.org 1QeBGO-0000xp-VE f93ba9fc5dc9d1a91b7ff48827aced98
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 1xx response semantics
Archived-At: <http://www.w3.org/mid/CAAbTgTtK3N=m-Hdz64ybr5xCsjXyVdZeF0AsnqHTxwgxGSO07Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/10897
X-Loop: ietf-http-wg@w3.org
Sender: ietf-http-wg-request@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1QeBGW-0002O9-VT@frink.w3.org>
Resent-Date: Tue, 05 Jul 2011 19:26:36 +0000

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