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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>>
>>>
>>>
>>>
>>
>

Reply via email to