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

just off the top of my head, if you

(a) can't rely on intermediaries to pass on headers they don't 
understand (e.g. which you could use to flag a requirement) - even 
though this is a requirement
(b) can't rely on Expects to be processed incorrectly by intermediaries
(c) can't rely on intermediaries to pass on methods they don't 
understand (even though the capability to be able to do this is required 
in the spec)

then your options are limited:

* another type of content encoding (e.g gzip -> packaged), with protocol 
overhead (restart position, markers  etc) multiplexed into the content.
* meta-protocol... something layered over normal HTTP GET and POST, 
where your negotiation is carried out over the message content rather 
than the headers.

personally though I'd be looking at relying on (a) above

Adrien



Brian McBarron wrote:
> On Thu, Apr 3, 2008 at 10:56 PM, Adrien de Croy <adrien@qbik.com 
> <mailto: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 <mailto: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
>     <mailto:mnot@yahoo-inc.com>
>     >>>>
>     >>>>
>     >>>>
>     >>>>
>     >>>>
>     >>>>
>     >>  --
>     >>
>     >>
>     >>  Mark Nottingham       mnot@yahoo-inc.com
>     <mailto:mnot@yahoo-inc.com>
>     >>
>     >>
>     >>
>     >>
>     >
>     >
>
>     --
>     Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
>
>

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

Received on Friday, 4 April 2008 23:56:01 UTC