Re: [google-gears-eng] Re: Deploying new expectation-extensions

On Thu, Apr 3, 2008 at 10:56 PM, Adrien de Croy <adrien@qbik.com> wrote:

> 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)


Not to beat a dead horse, but Expect _is_ end-to-end, according to the last
sentence here:

>    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.

However, there seem to be plenty of other reasons why Expect is not useful,
so it's probably moot.

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.


What we need to implement
http://code.google.com/p/google-gears/wiki/ResumableHttpRequestsProposal is
a mechanism which:
A) Is guaranteed to reach the origin-server (not discarded or refused by a
proxy)
B) The origin-server will refuse to process if it doesn't understand
These conditions are necessary so that the continuation of a request can't
result in unintended consequences if it ends up at the wrong origin-server.
Charles and I thought that the Expect header would accomplish these two
things.  Does anyone have a suggestion for a different mechanism that could
achieve the same effect?

Thanks,
Brian


>
>
> 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
>
>