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

Zhong Yu <> Tue, 23 April 2013 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8C6D21F91B2 for <>; Tue, 23 Apr 2013 10:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mxv5G6wlvPo1 for <>; Tue, 23 Apr 2013 10:43:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5DD9D21F95CE for <>; Tue, 23 Apr 2013 10:43:24 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UUhEk-0002cl-Gn for; Tue, 23 Apr 2013 17:42:38 +0000
Resent-Date: Tue, 23 Apr 2013 17:42:38 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UUhEb-0002c1-QA for; Tue, 23 Apr 2013 17:42:29 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UUhEa-0000BZ-CJ for; Tue, 23 Apr 2013 17:42:29 +0000
Received: by with SMTP id ta17so738624obb.26 for <>; Tue, 23 Apr 2013 10:42:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JnfqKgwMz5+RgB8kgxUQQz2+JS5yQQis4zlDyGGkNpQ=; b=Rx6qY5sHmgP+kjrxizZKjpIk+hhWV2LYoM4RKbxzhJQ8UbhtE4yAa1ztdbWC0xM9q4 w1kBwG62qLX4Z86/YEiX1QWRo0J8jqFL741GKCJ3XHGqJdsydDJdMcp4S0cm/iVE+vHI vvERD735jfcZCTnP66M0lY2xSCKduM7Xj/IvYDMhuscXmqL9oDLsv35rqmKCpoHBtYnW otcMq2g4X+lKO/HsSUJjGDZ+QkGYOvimDiUTvxUjv3EzbBHVu0aYJXtH97sZndVxGuc+ 6hFDQSVWtgZO5V4+QVfLPciX2OoO8wRWbcspjXHiEKWXrzUhExYauphr7mK2b53TU5ph gNdQ==
MIME-Version: 1.0
X-Received: by with SMTP id bm4mr2007960oec.108.1366738922235; Tue, 23 Apr 2013 10:42:02 -0700 (PDT)
Received: by with HTTP; Tue, 23 Apr 2013 10:42:02 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 23 Apr 2013 12:42:02 -0500
Message-ID: <>
From: Zhong Yu <>
To: Mark Nottingham <>
Cc: " Group" <>
Content-Type: multipart/alternative; boundary=089e01184cf8f5f3fb04db0ab353
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.704, BAYES_00=-1.9, 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: 1UUhEa-0000BZ-CJ 8f58bea8eea2711edc6cc905a193aaf5
Subject: Re: p2: Expect: 100-continue and "final" status codes
Archived-At: <>
X-Mailing-List: <> archive/latest/17509
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

#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

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

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.

#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?

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

On the other hand, the spec does not address connection management
adequately in the most important use case of the section. It currently says

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

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.

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

Zhong Yu

On Tue, Apr 23, 2013 at 2:22 AM, Mark Nottingham <> wrote:

> p2 explains the semantics of 100-continue: "If the origin server
> responds with a final status code, it must not have performed the request
> method and may either close the connection or continue to read and discard
> the rest of the request."
> In my (admittedly quick) testing, pretty much nobody does this, at least
> by default; i.e., if I send a GET to a server with Expect: 100-continue,
> it's going to give me a 200 or 30x, not a 417. Sure, they might send 417
> for a request with a body, but as written pretty much no one is conformant.
> One thing we could do would be to only place requirements upon proxies and
> servers when Expect: 100-continue is on a request with a body.
> Stepping back, though, I have to wonder if it's reasonable to only allow
> 100 (Continue) or, effectively, an error (since the request can't be
> "applied") in the presence of Expect: 100-continue. I've seen many
> implementations that purposefully ignore Expect: 100-continue and send back
> 200 (OK) responses to avoid the interop problems that expect/continue
> brings.
> OTOH if we do maintain the notion that a final response to an Expect:
> 100-continue request needs to NOT be applied on the server, we should use
> more specific terminology (i.e., say that it needs to be a 4xx or 5xx
> response status, not just a "final response.").
> Thoughts?
> --
> Mark Nottingham