httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: AW: AW: AW: 2.2 mod_http_proxy and "partial" pages
Date Mon, 02 Jan 2006 21:18:19 GMT


On 12/20/2005 10:14 PM, Ruediger Pluem wrote:

[..cut..]

> But you pointed me to an interesting thing: If the main response is
> T-E chunked and the backend error happened during the subrequest, the
> chunked filter may sometimes add the last-chunk marker (if the brigade
> containing the error bucket does *not* contain and eos bucket) and
> sometimes not (if the brigade containing the error bucket does contain
> an eos bucket).
> In the case that the broken backend happend on the main request the brigade
> always contains both buckets as they both get added to the brigade. But in
> the subrequest case I guess the eos bucket (of the subrequest) gets removed
> and the main request adds its own one later and maybe to a different brigade
> then the error bucket.

Meanwhile I took some time to investigate this further. I checked with the
subrequests caused by mod_include's #include virtual tag. In this case the
error bucket and the eos bucket seems to get passed to the chunk filter on
different brigades. This means the chunk filter does sent the last chunk marker
in this case. OTOH the error bucket causes the keepalive connection on the
main request to be closed and the partially generated page of mod_include gets
cached.
Before I take any further actions I would like to discuss the desired behaviour
in the subrequest case:

1. Proposal
If a subrequest has a broken backend also set r->no_cache for the main request
and ensure that the chunk filter does not sent the last chunk marker in this case.

2. Proposal
If a subrequest has a broken backend do not sent the error bucket. Only set r->no_cache
to ensure that this subrequest response does not get cached.

Further proposals are welcome.

Furthermore I am wondering if the current behaviour of mod_include is correct.
Shouldn't we prevent caching if any of the mod_include operations got wrong?
The broken backend for the #include virtual tag is only one example for this.
And if we decide that we should not cache in this situation, how do we let external
caches know? Should we also do not sent the last chunk marker in this case?


> I am even getting unsure if the brigade always contains error and eos bucket
> in the main request case, as there might happen an brigade split on the way
> to the chunk filter. Does anybody know if this can happen?
> 

Anybody found an answer to this question? If this is not sure it may be a good
idea to memorize the fact that the error bucket was seen in the context of
the chunk filter.

Regards

RĂ¼diger



Mime
View raw message