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

Mark Nottingham <mnot@mnot.net> Tue, 23 April 2013 07:23 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 8FABE21F94DF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 00:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.51
X-Spam-Level:
X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 yTDZSjcsl9th for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 00:23:25 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id DA03921F95F4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 00:23: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 1UUXZG-0006Ye-7L for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Apr 2013 07:23:10 +0000
Resent-Date: Tue, 23 Apr 2013 07:23:10 +0000
Resent-Message-Id: <E1UUXZG-0006Ye-7L@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 1UUXZC-0006Xa-GT for ietf-http-wg@listhub.w3.org; Tue, 23 Apr 2013 07:23:06 +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 1UUXZB-0000PT-Mg for ietf-http-wg@w3.org; Tue, 23 Apr 2013 07:23:06 +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 6100D509B8 for <ietf-http-wg@w3.org>; Tue, 23 Apr 2013 03:22:44 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <750CBB7A-3E82-4D2A-871E-159E9F030E6F@mnot.net>
Date: Tue, 23 Apr 2013 17:22:37 +1000
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
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.421, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UUXZB-0000PT-Mg 933da18eb7217f3795de5fede5642a87
X-Original-To: ietf-http-wg@w3.org
Subject: p2: Expect: 100-continue and "final" status codes
Archived-At: <http://www.w3.org/mid/750CBB7A-3E82-4D2A-871E-159E9F030E6F@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17490
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>

p2 5.1.1.1 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   http://www.mnot.net/