Charles Fry wrote:
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).
a) There's no Expect code related to status 102.
b) RFC4918 removed status 102 anyway, as nobody was implementing it.
I agree it would be nice to know what proxies actually do; maybe they do
not do what RFC2616 requires, and thus Expect could indeed be made
useful :-)
See
<http://lists.w3.org/Archives/Public/ietf-http-wg/2008AprJun/0043.html>
(I'd propose to continue the conversation over there).
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.
But that's a special case for "100-continue", which is a MUST level
feature for all HTTP/1.1 components anyway.
I think it's clear that a proxy that sees "Expect: foobar" will have to
immediately fail with status 417 if it doesn't know what "foobar" means.
BR, Julian
