> > William A. Rowe, Jr. wrote: > > Ruediger Pluem wrote: [..cut..]
> > > > Quick consideration; > > > > Rather than look for HTTP_BAD_GATEWAY error bucket, we can actually > > generalize the problem. ANY metadata bucket that isn't > recognized and > > handled by an intermediate filter probably indiciates a problem; and > > therefore the result is a non-cacheable, broken response. > > Actually two cases. In the error bucket case, it's > non-cacheable, and broken. So what do you think should be done in this case with respect to the 'brokenness'. 1. set r->connection->keepalive to AP_CONN_CLOSE 2. Do not sent the last chunk marker in the case of a chunked encoding response 3. Do 1. and 2. Next question is: Do we need to stop sending further data to the client immediately? > In the unrecognized bucket type case, it's non-cacheable (a > 'complex' response), > but it is likely serveable to the front end client. In both > cases, if mod_cache > doesn't grok what it sees, then something 'interesting' is > going on and we would > not want to deposit into the cache. I agree with the goals, but making it non cacheable is not easy to add to the current patch, because the HTTP_OUTERROR filter is a protocol filter that is run after the CACHE_SAVE filter. So setting r->no_cache there may be too late in the case that the error bucket and eos bucket are in the same brigade. This is the reason why we actually set r->no_cache on the proxy side in ap_proxy_backend_broke which is called from the scheme handlers. >From my current perspective this would mean that the CACHE_SAVE filter must be taught to deal with these buckets. But apart from the case that no content-length is present the CACHE_SAVE filter itself does not iterate over the brigade. So we would need to add an additional loop over the brigade inside of CACHE_SAVE filter to scan for these meta buckets. Furthermore I think we need to keep in mind that, if we think that this reponse is not worth caching, we may should make any upstream proxies think the same. In the case of a broken backend this is reached (depending on the transfer encoding) by 1. sending less content then the content-length header announces 2. do not send the last-chunk marker. But in the case of an unrecognized bucket type we must let the upstream proxies know that it is not cacheable via headers. But this could be impossible if the headers had been already sent. Regards Rüdiger
