You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2010/08/23 15:56:25 UTC
Plan to T&R 2.3.8
Either today or tomorrow I will be tagging and rolling httpd-2.3.8
Just a head's up.
Re: Plan to T&R 2.3.8
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 23, 2010, at 12: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.
>
> 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, ...
> 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.
>
> 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 :)
Re: Plan to T&R 2.3.8
Posted by Rainer Jung <ra...@kippdata.de>.
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
Re: Plan to T&R 2.3.8
Posted by Ruediger Pluem <rp...@apache.org>.
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.
Regards
Rüdiger
Re: Plan to T&R 2.3.8
Posted by Rainer Jung <ra...@kippdata.de>.
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.
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, ...
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.
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.
Regards,
Rainer