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." <[EMAIL PROTECTED]> 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.
*/
Regards
Rüdiger
