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

James M Snell <> Tue, 23 April 2013 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA71421F95DC for <>; Tue, 23 Apr 2013 08:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.578
X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h2Fyy2aGlrjN for <>; Tue, 23 Apr 2013 08:52:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EA9BF21F95D0 for <>; Tue, 23 Apr 2013 08:52:05 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UUfVL-0006EB-FH for; Tue, 23 Apr 2013 15:51:39 +0000
Resent-Date: Tue, 23 Apr 2013 15:51:39 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UUfVH-0006DV-Bh for; Tue, 23 Apr 2013 15:51:35 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UUfVC-0001rk-OA for; Tue, 23 Apr 2013 15:51:35 +0000
Received: by with SMTP id uk5so627620obc.39 for <>; Tue, 23 Apr 2013 08:51:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=78J1JPCYQkLroDqXx9nNn71pkm3CIStfdCjZjiJzfhQ=; b=UbpMHKMcuYdBkDhrtx+n6aRO+DTt+bc8jMUGYZUQskS15nQ1tXW2XPjkxmIlfujflS dticRkO867s+1LO1E//ufV2qtkJWhOFIkqYQ3WlLShSK0wdcX+reyQP7CE+5f6OzKQ2m haHknc67qKI7q/twSXes06j6JfK/EP4UKMfNgi7I2pC3Ds+gXYHmyrfCr9nmsRPMhpv9 9EAD5oYd3qCN999S5UHQs75AWeienlZYB9DdFLcfdj9ykfA0Dab8LCPXzHgyrz0ghQzF cTP3ZWoK5UUzSwgdRB4zznTlnaXPBhNDxwi6fIxXstUGb1JTG3zUURCu0iMLDJnjrKri Dg3A==
X-Received: by with SMTP id zc10mr12010313obb.80.1366732264719; Tue, 23 Apr 2013 08:51:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 23 Apr 2013 08:50:44 -0700 (PDT)
In-Reply-To: <>
References: <>
From: James M Snell <>
Date: Tue, 23 Apr 2013 08:50:44 -0700
Message-ID: <>
To: Mark Nottingham <>
Cc: " Group" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-0.8
X-W3C-Scan-Sig: 1UUfVC-0001rk-OA a61691a96f3c9761aa5a60e2050aeccd
Subject: Re: p2: Expect: 100-continue and "final" status codes
Archived-At: <>
X-Mailing-List: <> archive/latest/17506
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

For 1.x, I would say just leave this alone as is. I doubt there's
anything we can do that'll bring the non-conforming implementations
into line and it's not a critical enough of an issue to deserve
pushing on too much.

For 2.x, We ought to update the definition of Expect so that, for any
request method, an 100-Continue expectation MUST result in either a
RST_STREAM (if unsatisfied) or a 100 (Continue) as you suggest.

That said, I would also prefer that we discourage any further
definition of new expectations that dictate specific status response
codes from the server. The server ought to be free to return any
status it determines to be appropriate, and we now have the Prefer
header for allowing the client to communicate it's preferences while
still leaving the decision in the servers hands.

- James

On Tue, Apr 23, 2013 at 12: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