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 >>> >>> >>> >>> >> >