> -----Original Message----- > From: Graham Leggett > Sent: Freitag, 4. Juni 2010 15:44 > To: dev@httpd.apache.org > 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