Re: Deploying new expectation-extensions

Right. I'd missed that.

So in summary, new expectations are guaranteed to break on compliant
proxies? Sad.

Charles

On Thu, Apr 3, 2008 at 8:39 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 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 02:31:22 UTC