Subject: p2: Expectation extensions

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Apr 2013 17:22:36 +1000

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?

--
Mark Nottingham   http://www.mnot.net/

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 24 Apr 2013 01:57:54 +1200

> 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

---

From: James M Snell <[email-masked]>
Date: Tue, 23 Apr 2013 08:22:16 -0700

+1 ... what Amos said.

On Tue, Apr 23, 2013 at 6:57 AM, Amos Jeffries <[email-masked]> wrote:
>> 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.
>
> 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
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Apr 2013 08:14:01 +1000

On 23/04/2013, at 11:57 PM, Amos Jeffries <[email-masked]> wrote:

> 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.

Disallowing future extensions recognises that interop on this feature is low -- i.e., that deploying an extension here isn't likely to work well. I don't see much in the way of "concrete assurances" through its use at all, as a protocol designer; only a lot of nasty problems.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 26 Apr 2013 01:32:26 +0200

>disallowing further extensions here, and removing this requirement?

I would like to see a proper rewrite of the specification text here. In
general, I would disagree with changes as you propose; for instance, re-
moving the requirement entirely would seem to make it difficult to un-
derstand what the original idea behind `Expect` was, and it would seem
that pointing out interoperability problems with respect to `Expect` is
sufficient to discourage extensions; why should we forbid future experi-
ments that depend on `Expect` beyond that?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Zhong Yu <[email-masked]>
Date: Thu, 25 Apr 2013 18:48:40 -0500

How about the spec explicitly allows a server to ignore any expectation
(including 100-continue), since that is the reality anyway?

Zhong Yu

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 26 Apr 2013 02:01:45 +0200

>(including 100-continue), since that is the reality anyway?

It would be most helpful if anyone can demonstrate that that is indeed
the reality within some low margin of error. But then, too, I would like
to see some specific re-wording of the relevant text. It is not clear to
me that this properly reflects reality, and even if so, your proposal
seems to go even beyond what Mark Nottingham proposed, and it seems un-
likely to me that we would find consensus on ignoring `100-continue`.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/