Re: p2: Expectation extensions

Amos Jeffries <squid3@treenet.co.nz> Tue, 23 April 2013 13:59 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 EE2D421F96B6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 06:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.506
X-Spam-Level:
X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 3lFIqWLqi8Hp for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 06:59:00 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE5221F8E97 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 06:59:00 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUdjp-0005tj-SR for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Apr 2013 13:58:29 +0000
Resent-Date: Tue, 23 Apr 2013 13:58:29 +0000
Resent-Message-Id: <E1UUdjp-0005tj-SR@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1UUdji-0005sE-Fp for ietf-http-wg@listhub.w3.org; Tue, 23 Apr 2013 13:58:22 +0000
Received: from ip-58-28-153-233.static-xdsl.xnet.co.nz ([58.28.153.233] helo=treenet.co.nz) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1UUdjg-0003fk-7w for ietf-http-wg@w3.org; Tue, 23 Apr 2013 13:58:22 +0000
Received: from [192.168.2.7] (103-9-43-128.flip.co.nz [103.9.43.128]) by treenet.co.nz (Postfix) with ESMTP id E401BE6F39 for <ietf-http-wg@w3.org>; Wed, 24 Apr 2013 01:57:57 +1200 (NZST)
Message-ID: <51769362.808@treenet.co.nz>
Date: Wed, 24 Apr 2013 01:57:54 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <0509CFF1-0A48-46D9-93F0-5CEF60A9DE37@mnot.net>
In-Reply-To: <0509CFF1-0A48-46D9-93F0-5CEF60A9DE37@mnot.net>
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=-4.2
X-W3C-Hub-Spam-Report: AWL=-2.272, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UUdjg-0003fk-7w 8e691080e355aec681db93bbd3bd83ed
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p2: Expectation extensions
Archived-At: <http://www.w3.org/mid/51769362.808@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17503
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 23/04/2013 7:22 p.m., Mark Nottingham wrote:
> p2 5.1.1 requires that an unrecognised expectation be replied to with a 417 Expectation Failed.
>
> In my testing, it's fairly common for servers to ignore an unregistered expectation (e.g., "foo").
>
> Given how many problems we already have with Expect, should we consider disallowing further extensions here, and removing this requirement?

So whats gained by making it an expectation if the expectation is 
ignored? nothing.

Removing it also removes the fail-closed property of Expect:. I know the 
property is a great annoyance to new featrue rollout. But it does offer 
the concrete assurance that what is expected is supported which is quite 
useful when designing security related extensions. We have the Prefer 
header coming up to provide the expectation negotiation with fail-open 
semantics.

So overall I think we keep this, the servers not implementing it are 
already non-conformant with Expect.

Amos