Moving over to dev@ as this is a technical discussion.... On 10/27/2007 01:19 AM, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
