W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: Deploying new expectation-extensions

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 4 Apr 2008 11:39:24 +1100
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, google-gears-eng@googlegroups.com
Message-Id: <459BC80A-7E73-43C0-B204-26D13CFEA515@mnot.net>
To: "Charles Fry" <fry@google.com>

RFC 2616, section 1.3:

> server
> An application program that accepts connections in order to service  
> requests by sending back responses. Any given program may be capable  
> of being both a client and a server; our use of these terms refers  
> only to the role being performed by the program for a particular  
> connection, rather than to the program's capabilities in general.  
> Likewise, any server may act as an origin server, proxy, gateway, or  
> tunnel, switching behavior based on the nature of each request.

> origin server
> The server on which a given resource resides or is to be created.

> proxy
> An intermediary program which acts as both a server and a client for  
> the purpose of making requests on behalf of other clients. Requests  
> are serviced internally or by passing them on, with possible  
> translation, to other servers. A proxy MUST implement both the  
> client and server requirements of this specification. A "transparent  
> proxy" is a proxy that does not modify the request or response  
> beyond what is required for proxy authentication and identification.  
> A "non-transparent proxy" is a proxy that modifies the request or  
> response in order to provide some added service to the user agent,  
> such as group annotation services, media type transformation,  
> protocol reduction, or anonymity filtering. Except where either  
> transparent or non-transparent behavior is explicitly stated, the  
> HTTP proxy requirements apply to both types of proxies.


Cheers,


On 04/04/2008, at 11:34 AM, 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
>>
>>
>>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 4 April 2008 00:40:12 GMT

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