Re: p2: Requirements upon proxies for Expect

Willy Tarreau <w@1wt.eu> Sat, 20 April 2013 09:20 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 48E7521F91BB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Apr 2013 02:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.096
X-Spam-Level:
X-Spam-Status: No, score=-10.096 tagged_above=-999 required=5 tests=[AWL=0.503, 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 BxFWuFs12nsY for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Apr 2013 02:20:06 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AA07521F91B4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 20 Apr 2013 02:20:06 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UTTxK-0003Sm-PJ for ietf-http-wg-dist@listhub.w3.org; Sat, 20 Apr 2013 09:19:38 +0000
Resent-Date: Sat, 20 Apr 2013 09:19:38 +0000
Resent-Message-Id: <E1UTTxK-0003Sm-PJ@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UTTxH-0003S7-PT for ietf-http-wg@listhub.w3.org; Sat, 20 Apr 2013 09:19:35 +0000
Received: from 1wt.eu ([62.212.114.60]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UTTxH-0002Qg-4N for ietf-http-wg@w3.org; Sat, 20 Apr 2013 09:19:35 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r3K9Ipe0029101; Sat, 20 Apr 2013 11:18:51 +0200
Date: Sat, 20 Apr 2013 11:18:51 +0200
From: Willy Tarreau <w@1wt.eu>
To: Mark Nottingham <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <20130420091851.GS26517@1wt.eu>
References: <08A7729A-6B1F-46D2-AFA8-C37F6CFECD2A@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <08A7729A-6B1F-46D2-AFA8-C37F6CFECD2A@mnot.net>
User-Agent: Mutt/1.4.2.3i
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-2.593, RP_MATCHES_RCVD=-0.702, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UTTxH-0002Qg-4N d26754586dbcbf2a72665f18f77694a7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p2: Requirements upon proxies for Expect
Archived-At: <http://www.w3.org/mid/20130420091851.GS26517@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17420
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 Sat, Apr 20, 2013 at 07:00:19PM +1000, Mark Nottingham wrote:
> p2 5.1.1 "Requirements for HTP/1.1 proxies" bullet one effectively requires
> proxies to forward ALL requests with Expect: 100-continue if the inbound
> server is HTTP/1.1 -- even if the request is a GET.
> 
> I know that this isn't the intent, but that's how it reads; suggest
> qualifying this to only apply to requests with bodies.

Do you see any risk in applying this to any request ? I've been thinking
in the past about the possibility to use Expect to send non-idempotent
requests over existing connections without fearing the risk of a broken
connection, but the stupid situation where a client sends an empty POST
with Expect is still problematic. All this to say that there might be
some usages of Expect that are not covered here and not problematic
either.

> The next bullet requires proxies to respond with a 417 if the inbound server
> is HTTP/1.0. Just curious here - why? Wouldn't the maximally interoperable
> thing be to generate a 100-continue yourself? While the client *could*
> resubmit the request, they probably won't, because as far as they know, the
> origin told them not to.

That's exactly what I thought as well when reading this point ! And FWIW,
haproxy does so when it needs to parse part of the request body to pick
a server. I think that was the exact intended purpose of skipping as
many "100" responses as needed BTW.

Willy