W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: Expect header 'understand' vs 'meet'

From: Jan Algermissen <jan.algermissen@nordsc.com>
Date: Wed, 7 Sep 2011 22:18:26 +0200
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DA83652A-1D4A-4167-B757-69E539BB390C@nordsc.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Sep 7, 2011, at 10:09 PM, Julian Reschke wrote:

> On 2011-09-07 22:03, Jan Algermissen wrote:
>> Hi Julian,
>> 
>> 
>> On Sep 7, 2011, at 9:58 PM, Julian Reschke wrote:
>> 
>>> On 2011-09-07 21:38, Jan Algermissen wrote:
>>>> Dear WG,
>>>> 
>>>> I have a question on the Expect header section 9.2 in HTTPbis 16[1]
>>>> 
>>>> Is my understanding correct:
>>>> 
>>>> 1. A proxy that finds an expectation extension in the Expect header that it does understand but cannot meet must respond 417
>>>> 2. A proxy that finds an expectation extension in the Expect header that it does not understand ignores the extension
>>>> 
>>>> 
>>>> Jan
>>>> 
>>>> [1] http://www.ietf.org/id/draft-ietf-httpbis-p2-semantics-16.txt
>>> 
>>> "The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet."
>>> 
>>> I think that implies 417 for unknown extensions; how would the proxy "meet" the expectation when it doesn't know what it is?
>> 
>> 
>> fair enough.
>> 
>> But this means an extension can only be successfully defined and used when all intermediaries understand it - which is: never.
>> 
>> Or am I getting this wrong?
>> ...
> 
> No, that's unfortunately correct. Maybe we need to mention it.

Sorry to keep bugging - do you know the rationale behind this?

Can't I have a mechanism that allows the client to ask specifically the origin server to only work on my request if it exhibits a certain behavior? And isn't that (also) the idea behind 'Expect'?

Jan



> 
> Best regards, Julian
> 
Received on Wednesday, 7 September 2011 20:18:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:47 GMT