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:55:06 GMT
Err, sorry, we do see the EOC bucket, it's just after the ERROR and
EOS buckets (duh). :)


On Fri, May 23, 2008 at 1:31 PM, Adam Woodworth <mirkperl@gmail.com> wrote:
> And FWIW, when the "EOC" bucket is sent down, our mod_perl filter sees
> an "ERROR" bucket, i.e. the bucket type is "ERROR" not "EOC", if that
> matters.
>
>
> On Fri, May 23, 2008 at 1:19 PM, Adam Woodworth <mirkperl@gmail.com> wrote:
>> 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