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

Daniel Stenberg <daniel@haxx.se> Wed, 24 April 2013 17:52 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 BDDE121F8E9E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 10:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 NBCXTdkjuSI3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 10:52:47 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6D45F21F8A6B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Apr 2013 10:52:47 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UV3rj-0003aq-NG for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 17:52:23 +0000
Resent-Date: Wed, 24 Apr 2013 17:52:23 +0000
Resent-Message-Id: <E1UV3rj-0003aq-NG@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <daniel@haxx.se>) id 1UV3rb-0003XC-PP for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 17:52:15 +0000
Received: from giant.haxx.se ([80.67.6.50]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <daniel@haxx.se>) id 1UV3ra-0000L3-E5 for ietf-http-wg@w3.org; Wed, 24 Apr 2013 17:52:15 +0000
Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id r3OHpPcQ027216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Apr 2013 19:51:25 +0200
Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id r3OHpPH2027211; Wed, 24 Apr 2013 19:51:25 +0200
X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs
Date: Wed, 24 Apr 2013 19:51:25 +0200 (CEST)
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Ken Murchison <murch@andrew.cmu.edu>
cc: Willy Tarreau <w@1wt.eu>, ietf-http-wg@w3.org
In-Reply-To: <201304241734.r3OHYpEE032112@smtp.andrew.cmu.edu>
Message-ID: <alpine.DEB.2.00.1304241945200.7512@tvnag.unkk.fr>
References: <201304241734.r3OHYpEE032112@smtp.andrew.cmu.edu>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Received-SPF: pass client-ip=80.67.6.50; envelope-from=daniel@haxx.se; helo=giant.haxx.se
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=-3.117, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UV3ra-0000L3-E5 3049dee978150023dfdb472dcc977d51
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/alpine.DEB.2.00.1304241945200.7512@tvnag.unkk.fr>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17548
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, 24 Apr 2013, Ken Murchison wrote:

> Fair enough. But I would expect that a compliant 1.1 server would respond 
> with 100 (Continue) or failure pretty quickly -- well within the client's 
> "wait" interval.  Given that RFC 2616 is over a decade old, I would like to 
> think that any 1.1 implementation would be compliant with the Expect 
> behavior or should be deprecated.
>
> Unless we are worried about Expect:100-continue being sent to a 1.0 server, 
> allowing a client to start sending a body in the absence of 100 (Continue) 
> seems like a bad idea to me.  But if this behavior IS needed a client should 
> at least wait several seconds or something longer than the expected 
> roundtrip time.

curl/libcurl uses "Expect: 100-continue" by default when it sends larger 
POSTs. As a result, it is probably one of the most commonly disabled headers 
in curl requests. A significant amount of servers have problems with it, 
although I can't back this statement up with any numbers.

The nature of the problems can vary from blatantly refusing to respond when 
the header is present (or just return an error), to just not being aware of it 
and thus the wait-time is just wasted time that makes the operation much 
slower.

curl waits one second for a response before it continues anyway, and it is of 
course possibly too short in some edge cases but I don't think I've ever seen 
any problems due to that.

-- 

  / daniel.haxx.se