httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VIS <ruediger.pl...@vodafone.com>
Subject AW: AW: AW: 2.2 mod_http_proxy and "partial" pages
Date Tue, 10 Jan 2006 10:39:42 GMT

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

Mime
View raw message