- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 4 Apr 2008 11:39:24 +1100
- To: "Charles Fry" <fry@google.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, google-gears-eng@googlegroups.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 UTC