httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Plüm, Rüdiger, VF-Group" <ruediger.pl...@vodafone.com>
Subject RE: svn commit: r951222 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_disk_cache.c
Date Fri, 04 Jun 2010 14:15:22 GMT
 

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


 

Mime
View raw message