Re: Deploying new expectation-extensions

My reading of the spec was always that any server or proxy receiving an 
Expects header it didn't understand must bounce the request.  If a proxy 
relayed to the next hop there would be several problems:

a) it would no longer be a hop-by-hop header, but an end-to-end header 
(if all proxies in a chain did this, the request would make it all the 
way to the server)
b) The proxy still cannot perform any required processing because it 
doesn't know how to.  therefore such a mechanism couldn't be used to 
extend HTTP outside the bounds of the realm in which it already operates.

IMO I think this makes the Expects header pretty well useless, which is 
why I believe no-one has really bothered to implement it.  It merely 
invites all compliant agents to bounce your request, and therefore in 
the spirit of reducing round-trips to servers, and since there's 
generally another way around any problem,  people choose instead to 
avoid Expects (more reliable, fewer support calls etc).

However relying on non-compliance of proxies in this case would be 
foolhardy.  Changing the semantics of Expects I don't think is that 
great an option either (actually I'd vote to deprecate it along with 305 
Use Proxy)

However, I don't believe this use-case requires use of the Expects 
header.  What stops a server simply sending multiple 103 interim 
responses regardless of what the client sent?  Or a client could 
advertise the desire for such functionality with another header other 
than Expects. That's already explicitly allowed for in the spec... 
sending an Expects header in the request is simply asking anything along 
the chain to bounce the request if they are compliant and don't 
understand it. 

Adrien

Charles Fry wrote:
>> See:
>>   http://coad.measurement-factory.com/
>>
>>  A representative test is sending a request with
>>   Expect: 100-continueing
>>     
>
> And you define correct proxy behavior as sending a 417 when such a
> header is encountered? In other words your previous response suggests
> that most proxies _do not_ send a 417, but simply pass the header
> through, except for very recent Squid builds which send a 417 on an
> unknown expectation?
>
>   
>>  I don't see how you can read it both ways; e.g.,
>>
>>
>>     
>>>  This header field is defined with extensible syntax to allow for
>>>   future extensions. If a server receives a request containing an
>>>   Expect field that includes an expectation-extension that it does not
>>>   support, it MUST respond with a 417 (Expectation Failed) status.
>>>       
>
> I read this as applying to a non-proxy server. In other words, the
> final server for a given request. Obviously this server knows which
> expectation-extensions it supports, and clearly it must respond with a
> 417 when it receives an unsupported expectation.
>
>   
>>>   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
>>>   return a 417 (Expectation Failed) status if it receives a request
>>>   with an expectation that it cannot meet. However, the Expect
>>>   request-header itself is end-to-end; it MUST be forwarded if the
>>>   request is forwarded.
>>>       
>
> This is ambiguous in that it does not specify how a proxy determines
> that it cannot meet an unknown expectation. As far as I can tell, you
> and Julian are reading this to suggest that when a proxy sees an
> unknown expectation-extension it must return a 417. The way I read it,
> if a proxy receives an unknown expectation-extension then it must go
> about determining whether or not the expectation can be met by the
> next-hop server. If it knows the next-hop server to be HTTP/1.0 then
> it can clearly bail out immediately with a 417 (as specifically
> outlined in 8.2.3 for the 100-continue case). Otherwise the only way
> it can determine whether or not the expectation can be met is by
> forwarding it to the next-hop server.
>
> My reading of the utility of the hop-by-hop nature of the Expect
> mechanism (which corresponds very cleanly with our desired use case)
> is that Expect headers can be inserted by proxies (as specified in
> 10.1), allowing the proxy which inserted the header to eat any
> corresponding 1xx informational response that is returned.
>
> Now whether or not proxies in the wild behave this way or not is the
> other half of the question which I am trying to determine. :-)
>
> Charles
>
>   
>>  Cheers,
>>
>>
>>
>>
>>
>>  On 04/04/2008, at 10:47 AM, Charles Fry wrote:
>>
>>     
>>> Would you mind pointing us to the "related set of tests" which you refer
>>>       
>> to?
>>     
>>> Also, could you specify just what you imply by passing and failing
>>> these tests? Specifically, how is correct proxy behavior defined for
>>> unknown Expect requests (I could see arguments either way based on my
>>> reading of the HTTP protocol spec)?
>>>
>>> thanks,
>>> Charles
>>>
>>> On Thu, Apr 3, 2008 at 7:06 PM, Mark Nottingham <mnot@yahoo-inc.com>
>>>       
>> wrote:
>>     
>>>> I've tested a fairly wide variety of proxies with co-advisor; the only
>>>>         
>> one
>>     
>>>> that passed the related set of tests was very recent builds of Squid
>>>> (2.7DEVEL0). Everything else -- including Squid 2.6STABLE4 -- failed (it
>>>> would take some digging to figure out exactly where this happened,
>>>>         
>> unless
>>     
>>>> Henrik knows; regardless, I think it's safe to say that a very large
>>>> proportion of Squid's installed base fails as well).
>>>>
>>>> Cheers,
>>>>
>>>>
>>>> On 04/04/2008, at 6:01 AM, Julian Reschke wrote:
>>>>
>>>>
>>>>         
>>>>> Hi,
>>>>>
>>>>> interesting:
>>>>>
>>>>>           
>> <http://code.google.com/p/google-gears/wiki/ResumableHttpRequestsProposal>.
>>     
>>>>> In particular:
>>>>>
>>>>> "Note that section 14.20 of HTTP/1.1 indicates that "an HTTP/1.1 proxy
>>>>>
>>>>>           
>>>> MUST return a 417 (Expectation Failed) status if it receives a request
>>>>         
>> with
>>     
>>>> an expectation that it cannot meet". We expect that fully compliant
>>>>         
>> proxies
>>     
>>>> ignore Expect pragmas which they don't understand (as opposed to
>>>>         
>> understand
>>     
>>>> but cannot meet), but this remains to be verified in the wild."
>>>>
>>>>         
>>>>> So does anybody know that proxies do here?
>>>>>
>>>>> BR, Julian
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> --
>>>> Mark Nottingham       mnot@yahoo-inc.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>  --
>>
>>
>>  Mark Nottingham       mnot@yahoo-inc.com
>>
>>
>>
>>     
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Friday, 4 April 2008 02:55:42 UTC