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

Mark Nottingham <mnot@mnot.net> Wed, 24 April 2013 02:21 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 222EF21F930C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 19:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.462
X-Spam-Level:
X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 ouQmRYi6H6bX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 19:21:49 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCEA21F958D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 19:21:48 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUpJw-0002IC-FE for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 02:20:32 +0000
Resent-Date: Wed, 24 Apr 2013 02:20:32 +0000
Resent-Message-Id: <E1UUpJw-0002IC-FE@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UUpJr-0002HT-Lj for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 02:20:27 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UUpJq-0003lq-1v for ietf-http-wg@w3.org; Wed, 24 Apr 2013 02:20:27 +0000
Received: from [192.168.1.80] (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 98A1950AA3; Tue, 23 Apr 2013 22:20:03 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CACuKZqGmrDiNQvG0SVw=XXcy_n-BBxK-pnp+ar7uAbnwkumRag@mail.gmail.com>
Date: Wed, 24 Apr 2013 12:19:59 +1000
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B49FDCD-93D3-4DD8-BF05-DFB30511343E@mnot.net>
References: <750CBB7A-3E82-4D2A-871E-159E9F030E6F@mnot.net> <CACuKZqGmrDiNQvG0SVw=XXcy_n-BBxK-pnp+ar7uAbnwkumRag@mail.gmail.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-2.356, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UUpJq-0003lq-1v e7a6b37036ff2b547f67d1766264a13d
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/5B49FDCD-93D3-4DD8-BF05-DFB30511343E@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17515
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 24/04/2013, at 3:42 AM, Zhong Yu <zhong.j.yu@gmail.com>; wrote:

> #Expect 100-continue without a body
> 
> If a client sends a request without a body yet with a "Expect: 100-continue" header, the request ought to be considered a bad request, because of a previous requirement:
> 
>    o  A client MUST NOT send an Expect header field with the "100-
>       continue" expectation if it does not intend to send a payload
>       body.
> 
> However a server may not be able to detect all bad requests. If it sees a request without a body, it may simply assume that there's no 100-continue expectation.
> 
> The spec may add a leeway for server
> 
>    o  Upon receiving a request with "100-continue" expectation yet without a message body (i.e. both Transfer-Encoding and Content-Length are missing), an origin server SHOULD either respond with 400 (Bad Request), or ignore the expectation.

+1


> #Performing request method without reading request body
> 
> I don't understand why the origin server must not perform the request method if it opts not to read the request body. Even though it's probably the right thing to do in almost all cases, do we have to make it an absolute requirement? 

See below about recovery.


> #Managing connection
> 
> The last requirement for the origin server talks about requests *without* a "100-continue" expectation. Therefore it should not be in this section. The subject is covered very well in p1#6.6 already, I think we can simply delete it from this section.

+0.5 - I tend to agree, but don't mind too much if it stays.


> On the other hand, the spec does not address connection management adequately in the most important use case of the section. It currently says (paraphrasing)
> 
>     upon receiving a request that includes the 100-continue expectation, if the origin server responds with a final status code instead of 100 (Continue), after sending the response, it may either close the connection or continue to read and discard the rest of the request.
> 
> I think we can give better advice than that. If a server responds with a final status code instead of 100 (Continue)
> 
> 1. The response must be the last response on the connection. The response should contain "Connection: close" header. After the response is written, the server must initiate a lingering close of the connection (p1#6.6).

That seems too restrictive; as long as the server reads the rest of the request properly (discarding it), it should be able to recover and reuse the connection.


> 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.

Well, it has a choice; it can either close the connection, or continue sending and recover the connection. If it only has a few more bytes to write, and some requests queued, that might be preferable.

OTOH, given the general level of interop around Expect/Continue, maybe not.


> This is to avoid the RST problem if the client decides to start to write request body before receiving any response from the server.

I agree that the current language (esp. the use of MAY) is too ambiguous, and doesn't highlight why we're taking this approach (because the client might decide to start sending the body).


--
Mark Nottingham   http://www.mnot.net/