httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Woodworth" <mirkp...@gmail.com>
Subject Re: mod_proxy race condition bug #37770
Date Fri, 23 May 2008 17:19:20 GMT
I think that the deflate filter might need to be fixed in order to
work with this patch, I think the EOC bucket is causing the deflate
filter to cause apache to return a 200 OK to the client with a blank
page.  I had to make our mod_perl application remove the deflate
filter from the chain when we got an EOC in order to make this work.
So perhaps the deflate filter needs to handle this itself.  And
perhaps the same problem will affect many other filters.


On Thu, May 22, 2008 at 4:57 PM, Adam Woodworth <mirkperl@gmail.com> wrote:
> Ok my mistake, the setup I was using turned out to be the problem.
> I'm now able to see the patch working.
>
> Sorry about that.
>
> Thanks again Ruediger.
>
> Now I just have to modify our mod_perl application to behave correctly
> when mod_proxy sends EOC.
>
> Adam
>
>
> On Thu, May 22, 2008 at 4:28 AM, Ruediger Pluem <rpluem@apache.org> wrote:
>>
>>
>> On 05/21/2008 10:34 PM, Adam Woodworth wrote:
>>>
>>> I think there is a problem with r657443 (and thus I assume r645813):
>>>
>>> I applied the r657443 patch to my copy of the 2.2.8 official release
>>> source and it doesn't work right.  The problem is that the change to
>>> mod_proxy_http.c checks c->keepalives for a value, but c->keepalives
>>> is filled out by ap_http_header_filter(), which isn't called until
>>> later.  So, c->keepalives is always 0 at this point.  Which also means
>>
>> No, it is not always 0 at this point. It has a different value once the
>> connection to the client is not used for the first time.
>>
>>> that the "number of keepalives" message in the ap_log_rerror() msg
>>> isn't going to mean anything, but at this point it never reaches it.
>>>
>>> Also, I "patched the patch" to manually set c->keepalives to 1 for
>>> testing so that I could test out this r657443 patch.  However, what
>>> happened was that Apache would kick back an error page to the client,
>>> instead of just closing the connection.  So, no improvement.
>>>
>>> Has this patch been tested and verified anywhere?
>>
>> Yes, with the test code I posted here on list.
>>
>>
>> Regards
>>
>> RĂ¼diger
>>
>>
>>
>>
>

Mime
View raw message