You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Kew <ni...@webthing.com> on 2006/01/19 02:23:33 UTC
PR#38123
(resend - first attempt bounced mentioning www.sorbs.net)
Date: Thu, 19 Jan 2006 01:02:17 +0000 (GMT)
From: Nick Kew <ni...@webthing.com>
To: dev@httpd.apache.org
Subject: Re: [PATCH] Possible fix for report 38123
On Tue, 17 Jan 2006, Ruediger Pluem wrote:
>
> As far as I can see the root cause for the report 38123
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=38123) is the missing
> HTTP_IN filter in the error case. As I am currently unsure if this
creates
> any sideeffects, some remote eyes please :-).
>
>
> Index: server/protocol.c
> ===================================================================
> --- server/protocol.c»··(Revision 369902)
> +++ server/protocol.c»··(Arbeitskopie)
> @@ -934,6 +934,8 @@
> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> "client sent an unrecognized expectation
value of "
> "Expect: %s", expect);
> + ap_add_input_filter_handle(ap_http_input_filter_handle,
> + NULL, r, r->connection);
> ap_send_error_response(r, 0);
> ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r);
> ap_run_log_transaction(r);
That's the same bug and fix as PR#37790!
Which leads me to wonder, is there some good reason not to
insert the input filter unconditionally somewhere earlier in
request_post_read? As it stands, it looks as if your fix has
the same problem as mine: namely, it fixes the immediate problem
but leaves the bug waiting to manifest itself anew in other
early error conditions.
I'll be back on the job on Friday: someone ping me on IRC to
take a proper look.
--
Nick Kew
Re: PR#38123
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jan 21, 2006, at 5:01 PM, Nick Kew wrote:
> On Saturday 21 January 2006 19:09, Jim Jagielski wrote:
>> Can we back out the recently added patch, and revise the report
>> as STILL OPEN while this is being worked on, as far
>> as what is the correct solution.
>
> Note that the PR#37790 patch is already backported to 2.2.x branch.
> We're now looking for a revised patch that will fix all manifestations
> of this bug, so we'll need a vote on replacing that with a more
> generic
> fix.
>
> Any comments on Rüdiger's proposal in
> http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=113766861719828&w=2
> and followups?
>
Not yet: hoping to look and test it tomorrow and see
if there are any regressions, esp with non-HTTP protocols.
Re: PR#38123
Posted by Nick Kew <ni...@webthing.com>.
On Saturday 21 January 2006 19:09, Jim Jagielski wrote:
> Can we back out the recently added patch, and revise the report
> as STILL OPEN while this is being worked on, as far
> as what is the correct solution.
Note that the PR#37790 patch is already backported to 2.2.x branch.
We're now looking for a revised patch that will fix all manifestations
of this bug, so we'll need a vote on replacing that with a more generic
fix.
Any comments on Rüdiger's proposal in
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=113766861719828&w=2
and followups?
--
Nick Kew
Re: PR#38123
Posted by Jim Jagielski <ji...@jaguNET.com>.
Can we back out the recently added patch, and revise the report
as STILL OPEN while this is being worked on, as far
as what is the correct solution. Right now we have a
bug which is marked as FIXED, yet with a patch that
isn't likely the best (or "most correct") solution. As
such, it's likely this will fall through the cracks
and be forgotten, and not correctly handled.
On Jan 18, 2006, at 8:23 PM, Nick Kew wrote:
> (resend - first attempt bounced mentioning www.sorbs.net)
>
>
>
> Date: Thu, 19 Jan 2006 01:02:17 +0000 (GMT)
> From: Nick Kew <ni...@webthing.com>
> To: dev@httpd.apache.org
> Subject: Re: [PATCH] Possible fix for report 38123
>
> On Tue, 17 Jan 2006, Ruediger Pluem wrote:
>
>>
>> As far as I can see the root cause for the report 38123
>> (http://issues.apache.org/bugzilla/show_bug.cgi?id=38123) is the
>> missing
>> HTTP_IN filter in the error case. As I am currently unsure if this
> creates
>> any sideeffects, some remote eyes please :-).
>>
>>
>> Index: server/protocol.c
>> ===================================================================
>> --- server/protocol.c»··(Revision 369902)
>> +++ server/protocol.c»··(Arbeitskopie)
>> @@ -934,6 +934,8 @@
>> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
>> "client sent an unrecognized expectation
> value of "
>> "Expect: %s", expect);
>> + ap_add_input_filter_handle(ap_http_input_filter_handle,
>> + NULL, r, r->connection);
>> ap_send_error_response(r, 0);
>> ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r);
>> ap_run_log_transaction(r);
>
>
> That's the same bug and fix as PR#37790!
>
> Which leads me to wonder, is there some good reason not to
> insert the input filter unconditionally somewhere earlier in
> request_post_read? As it stands, it looks as if your fix has
> the same problem as mine: namely, it fixes the immediate problem
> but leaves the bug waiting to manifest itself anew in other
> early error conditions.
>
> I'll be back on the job on Friday: someone ping me on IRC to
> take a proper look.
>
> --
> Nick Kew
>
>