Re: mod_proxy, another case of ignoring the filter stack?
Sander Striker wrote: Ok, let me tell you why I want it. I want to implement a directive called CacheErrorServeStale, which, when it hits the CACHE_SAVE filter say with a 503 Service Temporarily Unavailable, and has a cache-stale_handle, continues as if it would have received a 304 Not Modified. That's one use of the request_status hook in mod_proxy. If mod_cache registered a handler for it, it could handle all instances where the proxy fails. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: mod_proxy, another case of ignoring the filter stack?
Brian Akins wrote: Sander Striker wrote: Ok, let me tell you why I want it. I want to implement a directive called CacheErrorServeStale, which, when it hits the CACHE_SAVE filter say with a 503 Service Temporarily Unavailable, and has a cache-stale_handle, continues as if it would have received a 304 Not Modified. That's one use of the request_status hook in mod_proxy. If mod_cache registered a handler for it, it could handle all instances where the proxy fails. No, mod_cache doesn't have to know what the origin is. It can be anything from a custom handler, a cgi, etc. This list happens to include mod_proxy, but I don't think we need to handle mod_proxy any differently. Rudigers suggestion of pushing an error bucket down the filter stack seems the best solution, which I'm working on implementing. Sander
Re: mod_proxy, another case of ignoring the filter stack?
On 12/29/2005 02:11 AM, Sander Striker wrote: [..cut..] First it doesn't seem to be the case that mod_proxy actually sets r-status in the case of an error (service temporarily unavailable caused by ProxyTimeout for instance). This may not matter for a handler, but... Just for my understanding: Is it really needed to set r-status in these cases? Isn't it sufficient if the handler just delivers the status code as return value in this case? Secondly in case we hit the cleanup phase (for example when we hit an error like above), mod_proxy doesn't allow filters that were set up a chance to run. I remember myself that we both worked on a similar problem with the default handler about 6 month ago: http://mail-archives.apache.org/mod_mbox/httpd-dev/200505.mbox/[EMAIL PROTECTED] At least in the default handler case I faced some problems with the error page handling if the EOS was sent down the filter chain for the error case by the handler. So I am not convinced right now that doing so is a good idea. Regards Rüdiger [..cut..]
Re: mod_proxy, another case of ignoring the filter stack?
Ruediger Pluem wrote: On 12/29/2005 02:11 AM, Sander Striker wrote: [..cut..] First it doesn't seem to be the case that mod_proxy actually sets r-status in the case of an error (service temporarily unavailable caused by ProxyTimeout for instance). This may not matter for a handler, but... Just for my understanding: Is it really needed to set r-status in these cases? Isn't it sufficient if the handler just delivers the status code as return value in this case? Secondly in case we hit the cleanup phase (for example when we hit an error like above), mod_proxy doesn't allow filters that were set up a chance to run. I remember myself that we both worked on a similar problem with the default handler about 6 month ago: Yeah, I recalled that discussion as well and thought: hey, more of the same. http://mail-archives.apache.org/mod_mbox/httpd-dev/200505.mbox/[EMAIL PROTECTED] At least in the default handler case I faced some problems with the error page handling if the EOS was sent down the filter chain for the error case by the handler. Hrmpf. I kindof hoped we finally resolved that, but I guess not. So I am not convinced right now that doing so is a good idea. Ok, let me tell you why I want it. I want to implement a directive called CacheErrorServeStale, which, when it hits the CACHE_SAVE filter say with a 503 Service Temporarily Unavailable, and has a cache-stale_handle, continues as if it would have received a 304 Not Modified. Ofcourse, this won't work if the cache save filter is never hit. Sander
Re: mod_proxy, another case of ignoring the filter stack?
On 12/30/2005 01:10 AM, Sander Striker wrote: Ruediger Pluem wrote: [..cut..] Ok, let me tell you why I want it. I want to implement a directive called CacheErrorServeStale, which, when it hits the CACHE_SAVE filter say with a 503 Service Temporarily Unavailable, and has a cache-stale_handle, continues as if it would have received a 304 Not Modified. Sounds like a good and nice idea. Ofcourse, this won't work if the cache save filter is never hit. This is very true. Just a weird thought: Have you tried sending an error bucket down the chain instead of the EOS bucket (without setting the status in mod_proxy) and removing it in CACHE_SAVE filter if CacheErrorServeStale is turned on and decides to deliver stale content? Of course it needs to be checked if error page handling still works in the case that CacheErrorServeStale is turned off. Regards Rüdiger
mod_proxy, another case of ignoring the filter stack?
Hi,
I'm timing out on this one, but I thought I'd throw it in here in
case someone has a bright idea on what is actually going on...
First it doesn't seem to be the case that mod_proxy actually
sets r-status in the case of an error (service temporarily
unavailable caused by ProxyTimeout for instance). This may
not matter for a handler, but...
Secondly in case we hit the cleanup phase (for example when
we hit an error like above), mod_proxy doesn't allow filters
that were set up a chance to run.
Hereby a tiny patch to fix these issues, though I'd like some
feedback whether this is the correct spot to do this in mod_proxy.
Thanks,
Sander
Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c (revision 359556)
+++ modules/proxy/mod_proxy.c (working copy)
@@ -790,6 +790,18 @@
proxy_run_request_status(access_status, r);
+if (!r-eos_sent) {
+apr_bucket_brigade *bb;
+apr_bucket *e;
+
+r-status = access_status;
+
+bb = apr_brigade_create(r-pool, r-connection-bucket_alloc);
+e = apr_bucket_eos_create(bb-bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, e);
+ap_pass_brigade(r-output_filters, bb);
+}
+
return access_status;
}
