Well, I guess that partly depends on how deployed proxies deal with
unrecognized Expect headers. Do any of you have any practical
knowledge of how current proxies deal with new Expect headers? There
does at least seem to be a precedent with WebDAV sending 102 status
codes (though I know nothing first-hand about this, including how well
it is received by proxies).

The HTTP spec does specify that the hop-to-hop decision MUST be made
at a protocol level
(<http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3>). In
other words, at least in the case of the Expect 100, a 417 is only
injected by a proxy with a known next-hop 1.0 or lower server. Similar
behavior with new Expect headers would be just fine in our case.

Charles

On Thu, Apr 3, 2008 at 1:54 PM, Julian Reschke <[EMAIL PROTECTED]> wrote:
> Charles Fry wrote:
>
> > Greetings Apache Developers,
> >
> > We have implemented an Apache module which needs to process incoming
> > Expect headers for non-100-expectations. The version of
> > server/protocol.c currently in the trunk has a hard-coded Expect
> > header check that handles "Expect: 100-continue", but fails on any
> > other expectation. It would seem consistent with the general
> > modularization of the the httpd server to be able to allow
> > non-100-expectations to be accepted and processed when desired. We
> > would be glad to help make the code modifications to accommodate such
> > functionality, if that would facilitate making such a change. Let us
> > know how to best proceed to enable non-100-expectations in httpd.
> >
>  > ...
>
>  Hm.
>
>  We talked about things like that in the WebDAV WG years ago.
>
>  The problem with Expect is that it's hop-to-hop...
> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.20>). So how
> do you deploy new expectation codes when you need to pass through proxies???
>
>  BR, Julian
>
>

Reply via email to