httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: Status of Bug # 39243
Date Sat, 03 Mar 2007 23:55:11 GMT

On 03/04/2007 12:28 AM, William A. Rowe, Jr. wrote:
> Nick Kew wrote:
>>On Sat, 03 Mar 2007 17:16:52 -0600
>>"William A. Rowe, Jr." <> wrote:
>>>I'm contemplating an HTTP/1.1-only solution, available only if the
>>>client is willing to present expect-header 100-continue, which would
>>>involve no buffering.
>>In principle:
>>+1 if it doesn't break current functionality with HTTP/1.0
>>-1 otherwise.
>>To the OP: why not apply the fix suggested in the bug comments?
>>Define the size you want to use.
> It wouldn't change existing behavior, if there's no expect-header, we
> cannot do a renegotiate because we have no way to confirm that the
> client isn't waiting for 100 continue.
> If the client presents 100 continue we could toggle this behavior to
> renegotiate immediately, prior to offering the 100 continue response.

I also thought along these lines, but it seems that IE / Firefox do not
send an Expect: 100-continue header with their POST requests or am I wrong?
In this case this would not help.

BTW: I think if the client sents an Expect: 100-continue header this already
works today, at least according to the comments in ssl_hook_Access of
ssl_engine_kernel.c and a first quick analysis of the code:

    /* If a renegotiation is now required for this location, and the
     * request includes a message body (and the client has not
     * requested a "100 Continue" response), then the client will be
     * streaming the request body over the wire already.  In that
     * case, it is not possible to stop and perform a new SSL
     * handshake immediately; once the SSL library moves to the
     * "accept" state, it will reject the SSL packets which the client
     * is sending for the request body.
     * To allow authentication to complete in this auth hook, the
     * solution used here is to fill a (bounded) buffer with the
     * request body, and then to reinject that request body later.



View raw message