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