You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2007/10/27 01:19:04 UTC
DO NOT REPLY [Bug 43711] - 100-continue response when 401 expected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43711>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43711
------- Additional Comments From nick@webthing.com 2007-10-26 16:19 -------
Thanks for entering this as a bug.
The basic problem is that the HTTP protocol input filter (ap_http_filter)
actually sends the 100-continue. That's way too early.
I think the fix should be to remove that code from the protocol filter, and send
the 100 response from a fixups hook. Bug me if I don't get around to doing
anything about it.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
Re: DO NOT REPLY [Bug 43711] - 100-continue response when 401 expected
Posted by Ruediger Pluem <rp...@apache.org>.
Moving over to dev@ as this is a technical discussion....
On 10/27/2007 01:19 AM, bugzilla@apache.org wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=43711>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
> INSERTED IN THE BUG DATABASE.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=43711
>
>
>
>
>
> ------- Additional Comments From nick@webthing.com 2007-10-26 16:19 -------
> Thanks for entering this as a bug.
>
> The basic problem is that the HTTP protocol input filter (ap_http_filter)
> actually sends the 100-continue. That's way too early.
I do not agree. Getting into ap_http_filter usually means that we are in the handler
and started reading the request body. Thats IMHO the correct point to send 100-continue.
>
> I think the fix should be to remove that code from the protocol filter, and send
> the 100 response from a fixups hook. Bug me if I don't get around to doing
> anything about it.
>
Actually I think sending it in the fixup hook would sent it even earlier as usually
the handler is the first hook to read from the input filter. And what if the handler
decides to reject the request for whatever reason? Then the client would have started
sending the body because we signaled so in the fixup hook.
It looks like to me something different is wrong here that causes this bug (maybe we
do a ap_discard_request_body too early). I haven't found time to dig any further.
Regards
Rüdiger