> -----Original Message-----
> From: Graham Leggett
> Sent: Freitag, 4. Juni 2010 15:44
> To: [email protected]
> Subject: Re: svn commit: r951222 - in /httpd/httpd/trunk:
> CHANGES modules/cache/mod_disk_cache.c
>
> On 04 Jun 2010, at 7:27 AM, Ruediger Pluem wrote:
>
> > Why is this needed? mod_cache itself does not allow partial
> content
> > to be cached
> > and even if this does not work it should be fixed there and not in
> > one of the
> > storage providers.
>
> mod_cache does allow a 206 to be cached, it is up to the cache
IMHO it does not (at least according to the comments and the code looks like
to follow these):
/*
* what responses should we not cache?
*
* At this point we decide based on the response headers whether it
* is appropriate _NOT_ to cache the data from the server. There are
* a whole lot of conditions that prevent us from caching this data.
* They are tested here one by one to be clear and unambiguous.
*/
if (r->status != HTTP_OK && r->status != HTTP_NON_AUTHORITATIVE
&& r->status != HTTP_MULTIPLE_CHOICES
&& r->status != HTTP_MOVED_PERMANENTLY
&& r->status != HTTP_NOT_MODIFIED) {
/* RFC2616 13.4 we are allowed to cache 200, 203, 206, 300, 301 or 410
* We don't cache 206, because we don't (yet) cache partial responses.
* We include 304 Not Modified here too as this is the origin server
* telling us to serve the cached copy.
*/
if ((exps != NULL || cc_out != NULL)
&& r->status != HTTP_PARTIAL_CONTENT) {
/* We are also allowed to cache any response given that it has a
* valid Expires or Cache Control header. If we find a either of
* those here, we pass request through the rest of the tests. From
* the RFC:
*
* A response received with any other status code (e.g. status
* codes 302 and 307) MUST NOT be returned in a reply to a
* subsequent request unless there are cache-control directives or
* another header(s) that explicitly allow it. For example, these
* include the following: an Expires header (section 14.21); a
* "max-age", "s-maxage", "must-revalidate", "proxy-revalidate",
* "public" or "private" cache-control directive (section 14.9).
*
* But do NOT store 206 responses in any case since we
* don't (yet) cache partial responses.
*/
}
else {
reason = apr_psprintf(p, "Response status %d", r->status);
}
}
> implementation (mod_disk_cache) to decide whether it wants to
> handle a
> 206 or not.
>
> mod_cache is not the place to fix this. It is entirely valid for a
So you think that should be fixed in every single provider?
I am currently not convinced that any provider could cache a 206 with
the current mod_cache infrastructure.
> cache implementation to be given the opportunity to cache a 206, if
Right, RFC2616 permits caching 206's.
Regards
Rüdiger
