Bug 55156 - mod_cache not respecting s-maxage cache-control header
Summary: mod_cache not respecting s-maxage cache-control header
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_cache (show other bugs)
Version: 2.4.4
Hardware: PC Linux
: P2 normal with 1 vote (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-28 20:02 UTC by Greg Martyn
Modified: 2019-05-11 00:26 UTC (History)
0 users



Attachments
Don't check the expiration time if the expiration header isn't set (1.14 KB, patch)
2013-07-02 01:35 UTC, Greg Martyn
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Martyn 2013-06-28 20:02:56 UTC
I'm using mod_cache's CacheQuickHandler.

My response header has "Cache-Control: max-age=0, s-maxage=86400, public", but my log shows "Expires header already expired; not cacheable". S-maxage should be overriding the expires header. (and the max-age cache-control directive)

Full response headers:
HTTP/1.1 200 OK
Date: Fri, 28 Jun 2013 19:57:23 GMT
Server: Apache/2.4.4 (Unix) OpenSSL/1.0.1e PHP/5.5.0
X-Frame-Options: SAMEORIGIN
X-Powered-By: PHP/5.5.0
Cache-Control: max-age=0, s-maxage=86400, public
Expires: Fri, 28 Jun 2013 19:57:23 GMT
Vary: Accept-Encoding
Strict-Transport-Security: max-age=16070400
X-Cache: MISS from theshadestore.com
Transfer-Encoding: chunked
Content-Type: application/json
Comment 1 Greg Martyn 2013-06-28 20:07:22 UTC
Someone else noticed this a while ago, but I don't see any open bug reports for it:

https://mail-archives.apache.org/mod_mbox/httpd-users/200909.mbox/%3C4A9EB6E1.2080704@googlemail.com%3E
Comment 2 Eric Covener 2013-06-28 20:52:45 UTC
Not tested, this just pretends Expires and max-age are not there if s-maxage is.

http://people.apache.org/~covener/patches/PR55156.diff
Comment 3 Graham Leggett 2013-06-30 12:21:48 UTC
There has recently been a significant amount of work fixing RFC violations highlighted by the CoAdvisor test suite, I suspect this may already have been fixed:

https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/CHANGES

Would it be possible to test v2.4.5-dev (failing that, trunk) and check whether it still shows this problem?
Comment 4 Greg Martyn 2013-07-02 00:29:09 UTC
I had some luck with Eric's patch, but that seemed to stop working once the cache was cleared. I was unable to get 2.4.x or trunk to return a cache hit.
Comment 5 Greg Martyn 2013-07-02 00:31:23 UTC
After clearing the cache when using Eric's patch, it went back to "Expires header already expired; not cacheable". Before that it was reporting cache hits.
Comment 6 Greg Martyn 2013-07-02 01:35:53 UTC
Created attachment 30518 [details]
Don't check the expiration time if the expiration header isn't set

Don't validate the expiration time if the expiration header isn't set

I also chose to set control.max_age_value to control.s_maxage_value (instead of 0) because the spec describes s-maxage as simply overriding max-age.
Comment 7 Eric Covener 2015-12-07 23:30:58 UTC
I recently "re-discovered" this issue, here is what I had in my sandbox when I came to bugzilla:

http://people.apache.org/~covener/patches/trunk-cache-smaxage_and_etag.diff

This hides looking at Expires when s-maxage or smaxage were set, and uses s-maxage over maxage when calculating the internal expiration time.
Comment 8 Mark Nottingham 2019-05-11 00:26:10 UTC
I don't see this in my testing:
  https://cache-tests.fyi/?id=freshness-max-age-s-maxage-shared-shorter-expires#