Re: [users@httpd] mod_cache: possible bug with cache-control max-age vs expires (rfc2616)

[Igor Galić <i....@brainsware.org>]

Hi Frank,

> Morning list;

This list might be the wrong place to discuss such matters.

> While playing around with mod_cache & Drupal (Pressflow actually) I
> think I may have found a problem in mod_cache's implementation of the
> http/1.1 cache expiration mechanism.
> 
> According to the spec (rfc 2616, 14.9.3), cache-control max-age
> overrules expires:
> "If a response includes both an Expires header and a max-age
> directive, the max-age directive overrides the Expires header, even
> if
> the Expires header is more restrictive. This rule allows an origin
> server to provide, for a given response, a longer expiration time to
> an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be
> useful if certain HTTP/1.0 caches improperly calculate ages or
> expiration times, perhaps due to desynchronized clocks."

I believe we're talking about this PR here
https://issues.apache.org/bugzilla/show_bug.cgi?id=35247

> Indeed, this part of the spec is used by Pressflow to tell http/1.0
> caches not to cache (with an expires in the past) because those don't
> understand vary:cookie, while cache-control's max-age specifies a
> value > 0, which should allow http/1.1 caches to store the object.
> 
> Now while testing Pressflow with mod_cache (with Apache's loglevel
> set
> to debug), I got "not cached. Reason: Expires header already expired,
> not cacheable" entries in my logfile, although there was a valid
> cache-control:max-age present. Judging by the mod_cache.c sourcecode
> (warning: i'm not a C-developer by any account) it indeed seems
> Expires in the past are enough to not cache an object, disregarding a
> potential cache-control's max-age;
> 
> ---
> else if (exp != APR_DATE_BAD && exp < r->request_time)
>     {
>         /* if a Expires header is in the past, don't cache it */
>         reason = "Expires header already expired, not cacheable";
>     }
> ---
> (cfr.
> http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/modules/cache/mod_cache.c
> line 503)
> 
> So shouldn't the condition be expanded with checks on
> cache-control:max-age to comply with the spec? Or am I missing
> something here?
> 
> Kind regards,
> frank
> -----
> http://blog.futtta.be/

So long,
i

-- 
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/

Re: [users@httpd] mod_cache: possible bug with cache-control max-age vs expires (rfc2616)

[frank goossens <fu...@gmail.com>]

2010/10/13 Igor Galić <i....@brainsware.org>
> This list might be the wrong place to discuss such matter

just following the bug reporting guidelines on
http://httpd.apache.org/bug_report.html :-)

> I believe we're talking about this PR here
> https://issues.apache.org/bugzilla/show_bug.cgi?id=35247

yes and no; "my" issue and the one in that PR are related, 35247 is
about priority of s-maxage on max-age, while my problem is with
max-age which should have priority on expires..

but Henrik Nordstrom's (who works on squid btw) comment 5 in the PR
(https://issues.apache.org/bugzilla/show_bug.cgi?id=35247#c5) does
touch upon expires vs max-age as well;
"If CC max-age is set in the response then this overrides any Expires
response header and the Expires header is not relevant for the
expiry/freshness calculation."

so the question is; how can these (related) problems be tackled?

frank

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org