Re: Deploying new expectation-extensions

Jamie, thanks for the detailed explanation. We were approaching the
spec from our current requirements without the added insight of
additional use cases. Your description went a long way in clarifying
the possible intent of Expect, and in making it seem a bit less
broken.

cheers,
Charles

On Thu, Apr 3, 2008 at 8:54 PM, Jamie Lokier <jamie@shareable.org> wrote:
> 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 02:36:01 UTC