On 24.08.2010 07:56, Ruediger Pluem wrote:
On 08/23/2010 06:53 PM, Rainer Jung wrote:
On 23.08.2010 15:56, Jim Jagielski wrote:
Either today or tomorrow I will be tagging and rolling httpd-2.3.8
Just a head's up.
I played a bit with the new http proxy ping. If it is activated and the
proxy receives a POST request via HTTP/1.1, it always returns "HTTP/1.1
100 Continue" to the original client, independent of whether the client
itself requested this (Expect header set or not) and independent of
whether a timeout occured during the backend ping.
My thought on Jim's original intention was that this should not happen and
that this 100 Continue should be swallowed by the proxy if the proxy added
the Expect header.
RFC 2616 says in 8.2.3:
- An origin server SHOULD NOT send a 100 (Continue) response if
the request message does not include an Expect request-header
field with the "100-continue" expectation, ...
SHOULD NOT does not sound good.
There is an exception to this rule: for
compatibility with RFC 2068, a server MAY send a 100 (Continue)
status in response to an HTTP/1.1 PUT or POST request that does
not include an Expect request-header field with the "100-
continue" expectation. This exception, the purpose of which is
to minimize any client processing delays associated with an
undeclared wait for 100 (Continue) status, applies only to
HTTP/1.1 requests, and not to requests with any other HTTP-
version value.
This sounds better, but requires us to check that our client sent in
a HTTP/1.1 request.
When using a 1.0 client (curl -0) I did *not* receive the expectation at
the client. S this seems fine.
On 23.08.2010 22:33, Jim Jagielski wrote:
>> So we don't really break the spec but it could be that some clients
might not tolerate any expectation response they haven't asked for.
>
> Yeah... let's use the release to gain some additional real-world
> feedback and then decide whether to rip it out :)
I agree.
Regards,
Rainer
