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

Ken Murchison <murch@andrew.cmu.edu> Wed, 24 April 2013 19:22 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 9461621F93D0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 12:22:26 -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=[AWL=0.000, 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 kODUwPMHWHst for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 12:22:26 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id DF11221F93CD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Apr 2013 12:22:25 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UV5GA-0001lK-HU for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 19:21:42 +0000
Resent-Date: Wed, 24 Apr 2013 19:21:42 +0000
Resent-Message-Id: <E1UV5GA-0001lK-HU@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <murch@andrew.cmu.edu>) id 1UV5G6-0001kb-9g for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 19:21:38 +0000
Received: from smtp.andrew.cmu.edu ([128.2.11.96]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <murch@andrew.cmu.edu>) id 1UV5G5-0004Wh-Jh for ietf-http-wg@w3.org; Wed, 24 Apr 2013 19:21:38 +0000
Received: from [192.168.137.21] (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id r3OJKnKg001888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Apr 2013 15:20:50 -0400
Message-ID: <51783090.5020103@andrew.cmu.edu>
Date: Wed, 24 Apr 2013 15:20:48 -0400
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 2.0.0.23 (X11/20090825)
MIME-Version: 1.0
To: Willy Tarreau <w@1wt.eu>
CC: ietf-http-wg@w3.org
References: <20130424170638.GD19750@1wt.eu> <201304241734.r3OHYpEE032112@smtp.andrew.cmu.edu> <20130424174716.GF19750@1wt.eu>
In-Reply-To: <20130424174716.GF19750@1wt.eu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.4.9.4220
X-SMTP-Spam-Clean: 8% ( BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_POOLED_2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0)
X-SMTP-Spam-Score: 8%
X-Scanned-By: MIMEDefang 2.60 on 128.2.11.96
Received-SPF: none client-ip=128.2.11.96; envelope-from=murch@andrew.cmu.edu; helo=smtp.andrew.cmu.edu
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-2.234, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UV5G5-0004Wh-Jh 067ef4c84126114099adc39833b88053
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/51783090.5020103@andrew.cmu.edu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17556
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>

Willy Tarreau wrote:
> On Wed, Apr 24, 2013 at 01:34:51PM -0400, Ken Murchison wrote:
>   
>> On Wed, 24 Apr 2013 13:06:38 -0400, Willy Tarreau wrote:
>>     
>>> 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.
>>>       
>> 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.
>>
>> Am I way off base here?  I'm not privy to all of the history of HTTP.  I only
>> started developing our CalDAV server a couple of years ago.
>>     
>
> No you're perfectly right, but you forgot about the messy case where the 1.1
> client sends via a 1.0 gateway to an 1.1 server and the 1.0 gateway needs to
> validate the contents before passing the request :-)
>   

Yes, ignorance on my part.  If the client-side special handling needs to 
stay because of 1.0 intermediaries, then so be it.  But I don't think 
there should be any wiggle room for 1.1 servers at this point in the game.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University