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

Zhong Yu <zhong.j.yu@gmail.com> Wed, 24 April 2013 16:29 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 D8A1821F8624 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 09:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aX8VV0TZnAXL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 09:29:18 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 442F121F842F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Apr 2013 09:29:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UV2YK-0006Sz-LF for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 16:28:16 +0000
Resent-Date: Wed, 24 Apr 2013 16:28:16 +0000
Resent-Message-Id: <E1UV2YK-0006Sz-LF@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <zhong.j.yu@gmail.com>) id 1UV2YF-0006Rs-Hm for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 16:28:11 +0000
Received: from mail-ob0-f179.google.com ([209.85.214.179]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <zhong.j.yu@gmail.com>) id 1UV2YA-0001a2-MH for ietf-http-wg@w3.org; Wed, 24 Apr 2013 16:28:11 +0000
Received: by mail-ob0-f179.google.com with SMTP id oi10so1599165obb.24 for <ietf-http-wg@w3.org>; Wed, 24 Apr 2013 09:27:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ze4Sr7HFNPwOPZaAgrciZwu3ezkAoMgIMEZ5QkVxWX4=; b=M9FXQf7C/qyMr+nZYRgdcHV7Uq5zq4F5XmhrEEa6JBFRfTiQ+7x5WQ8egOjLiZUNjM DKpdMwhdMideeKRFLyzalijsajx8Cu5OW+vtsdAiPTZLkpjlGfPRfRXqNmrCXLHUnnfH BJ/qGSZQqvnlZFFt1h4Hw8qdLHVY+LJn/fks2Agt5+hnluV3PFD/zKytxC8n3pUs47PW g8/zH/8nofgGeauVfQU4OuTFtcxlYe759N01bSi8H7/FJ6iTIXdOk6+QbD6L7hUe2+FI PWDSRA62zpdMX0Cz4m+uzb+A2ju/72gO+INAo3OPIu9y3gdlzbK6fFmaZc6AkHJyzOqS TKXw==
MIME-Version: 1.0
X-Received: by 10.182.24.5 with SMTP id q5mr4266204obf.97.1366820860655; Wed, 24 Apr 2013 09:27:40 -0700 (PDT)
Received: by 10.76.22.130 with HTTP; Wed, 24 Apr 2013 09:27:40 -0700 (PDT)
In-Reply-To: <5B49FDCD-93D3-4DD8-BF05-DFB30511343E@mnot.net>
References: <750CBB7A-3E82-4D2A-871E-159E9F030E6F@mnot.net> <CACuKZqGmrDiNQvG0SVw=XXcy_n-BBxK-pnp+ar7uAbnwkumRag@mail.gmail.com> <5B49FDCD-93D3-4DD8-BF05-DFB30511343E@mnot.net>
Date: Wed, 24 Apr 2013 11:27:40 -0500
Message-ID: <CACuKZqFBSqLG1kdgDZONqgP5B4kjyZSMrwwN_NXqLRSV3sn41w@mail.gmail.com>
From: Zhong Yu <zhong.j.yu@gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a11c2af90df4e1904db1dc7f7
Received-SPF: pass client-ip=209.85.214.179; envelope-from=zhong.j.yu@gmail.com; helo=mail-ob0-f179.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.655, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UV2YA-0001a2-MH 3c84596f4e07b63e9f9b97fa84ad53ba
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/CACuKZqFBSqLG1kdgDZONqgP5B4kjyZSMrwwN_NXqLRSV3sn41w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17537
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 Tue, Apr 23, 2013 at 9:19 PM, Mark Nottingham <mnot@mnot.net>; wrote:

>
> 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.
>
>
You are right, scratch my proposal.


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