Re: #458: Requirements upon proxies for Expect

Amos Jeffries <squid3@treenet.co.nz> Wed, 05 June 2013 04:02 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 6933921F9AD5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 4 Jun 2013 21:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 DQsGEUhPiL-v for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 4 Jun 2013 21:02:02 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B62A521F9A9C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 4 Jun 2013 21:01:56 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uk4tE-0004ra-0Y for ietf-http-wg-dist@listhub.w3.org; Wed, 05 Jun 2013 04:00:00 +0000
Resent-Date: Wed, 05 Jun 2013 04:00:00 +0000
Resent-Message-Id: <E1Uk4tE-0004ra-0Y@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1Uk4ss-0004pf-Ju for ietf-http-wg@listhub.w3.org; Wed, 05 Jun 2013 03:59:38 +0000
Received: from ip-58-28-153-233.static-xdsl.xnet.co.nz ([58.28.153.233] helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1Uk4sn-0007Dv-W6 for ietf-http-wg@w3.org; Wed, 05 Jun 2013 03:59:38 +0000
Received: from [192.168.2.6] (103-9-43-156.flip.co.nz [103.9.43.156]) by treenet.co.nz (Postfix) with ESMTP id 156D5E70E8 for <ietf-http-wg@w3.org>; Wed, 5 Jun 2013 15:59:09 +1200 (NZST)
Message-ID: <51AEB78C.5050506@treenet.co.nz>
Date: Wed, 05 Jun 2013 15:59:08 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <08A7729A-6B1F-46D2-AFA8-C37F6CFECD2A@mnot.net> <20130420091851.GS26517@1wt.eu> <3C8151C1-B850-4960-A2FD-305BD7CD2CAD@mnot.net> <20130531061329.GF19728@1wt.eu> <EAD0EAA7-1D19-4B83-B5A3-6FBC0D5371D2@mnot.net> <20130604051259.GA11016@1wt.eu>
In-Reply-To: <20130604051259.GA11016@1wt.eu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=58.28.153.233; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-3.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1Uk4sn-0007Dv-W6 bcb07f1420aab1d126ce41108cdac572
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #458: Requirements upon proxies for Expect
Archived-At: <http://www.w3.org/mid/51AEB78C.5050506@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18179
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 4/06/2013 5:12 p.m., Willy Tarreau wrote:
> On Tue, Jun 04, 2013 at 11:37:14AM +1000, Mark Nottingham wrote:
>> So, you'd like to relax this requirement for all connections, not just when
>> the proxy knows that the forward hop is 1.0?
> Yes, for three reasons :
>    - it's the only way for a content analyser (think anti-virus) to get
>      the payload ;
>    - clients already expect to receive multiple non-final 100 responses
>    - we never know for sure the version of the next hop, and deciding a
>      behaviour rule this way could probably introduce more confusion than
>      having a general one
>
>> I think that's sensible, but it's a bigger change; what do others think?

I agree it is sensible for any recipient to be able to 100 or 417 the 
request. But we should however highlight that 100 means some (possibly 
very large) payload will be transferred, and that sending the payload 
may result in extreme bandwidth waste and may be at odds with the 
client-origin webapps intention for it. ie discourage but permit.

The example case here is; the server may only be sending 100-continue to 
POST if a certain content-encoding or extension header is present. Think 
about a certain unnamed video uploader which requires "X-Account: 
<secure hash>" and responds 200 immediately with a form-based login page 
if the credentials are absent.

For that matter, there is no explicit restriction on which party in the 
chain can add Expect: is there? so there is a potential case for Expect: 
being sent and responded by two hops in the middle of a chain.

Amos