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
