Re: Deploying new expectation-extensions

Charles Fry wrote:
> > >   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.

Wow, I'm amazed that anyone had that interpretation.

My reading of expectation-extensions is that it's absolutely intended
for a proxy to return 417 if it doesn't recognise the expectation
_itself_, to allow HTTP to be extended with new features in a way
which doesn't break over existing servers, including proxies.

E.g. if there was some new message boundary encoding used in a
request, you'd accompany it with an expectation so that a proxy which
doesn't know that encoding would return 417 rather than
misinterpreting the message.  The client would then retry with a more
backward compatible encoding.  Things like multiplexing extensions and
pipelining improvements would use this.  (But not if proxies aren't
returning 417s).

In general with future/backward-compatibility of protocols, file
formats etc., it's useful to have an extensible way to say "this
message has features which _may_ be supported", and "this message has
features which _must_ be supported".  For HTTP, I understood Expect is
the "must" part of that.  But not if proxies ignore it.

My reading of "Expect: 100-continue" is that the proxies _themselves_
can return "100 Continue" responses (as well as eating the one
produced by the next hop, if any.

-- Jamie

Received on Friday, 4 April 2008 00:55:01 UTC