Re: p2: Expect: 100-continue and "final" status codes

Willy Tarreau <w@1wt.eu> Wed, 24 April 2013 17:07 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 5936F21F961E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 10:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.252
X-Spam-Level:
X-Spam-Status: No, score=-10.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBW0WZ2+uzSt for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 10:07:55 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D38CB21F95F4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Apr 2013 10:07:55 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UV3A3-0004z4-Ab for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 17:07:15 +0000
Resent-Date: Wed, 24 Apr 2013 17:07:15 +0000
Resent-Message-Id: <E1UV3A3-0004z4-Ab@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UV39w-0004yP-1c for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 17:07:08 +0000
Received: from 1wt.eu ([62.212.114.60]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UV39r-0003I9-3v for ietf-http-wg@w3.org; Wed, 24 Apr 2013 17:07:08 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r3OH6cdH022435; Wed, 24 Apr 2013 19:06:38 +0200
Date: Wed, 24 Apr 2013 19:06:38 +0200
From: Willy Tarreau <w@1wt.eu>
To: Ken Murchison <murch@andrew.cmu.edu>
Cc: ietf-http-wg@w3.org
Message-ID: <20130424170638.GD19750@1wt.eu>
References: <CACuKZqGmrDiNQvG0SVw=XXcy_n-BBxK-pnp+ar7uAbnwkumRag@mail.gmail.com> <51780FBA.3080706@andrew.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51780FBA.3080706@andrew.cmu.edu>
User-Agent: Mutt/1.4.2.3i
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=-3.059, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UV39r-0003I9-3v 29948996b536bfb3ce0bfb8f3afeafdd
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p2: Expect: 100-continue and "final" status codes
Archived-At: <http://www.w3.org/mid/20130424170638.GD19750@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17543
X-Loop: ietf-http-wg@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>

On Wed, Apr 24, 2013 at 01:00:42PM -0400, Ken Murchison wrote:
> >2. If the client receives a final status code instead of 100 
> >(Continue), it
> >should stop sending request body if it is doing so; it must close the
> >connection after the response is received.
> 
> I don't understand point #2.  If the client submits a request with 
> Expect:100-continue, I would assume that the client MUST NOT send any 
> part of the body until it receives 100 (Continue) from the server.  If 
> the server rejects the request based on the headers (with 412, 415, 417, 
> etc) there should be no body data in the pipe for either the client or 
> server to worry about, correct?

In fact the client can decide that it's been waiting too long for 100
and decides to send anyway (because some old servers or intermediaries
do not know about Expect and will wait).

So what is generally done is that the client sends the headers, waits a
bit then starts to send data if the server does not respond.

Implementation of expect+100 seems to be a real mess at some places,
but when it works it prove to be quite useful.

Willy