[Plugin: W3 Total Cache] expiry header set incorrectly?

  • Resolved efikim

    (@efikim)


    13 years, 8 months ago

    I’ve updated to 0.9.1.1 and it seems to me that the header is being calculated incorrectly for media files.

    on http://words.mikefinley.co.uk I have the media expires header lifetime set to 432000 seconds (4 days), and expect this to mean that it will expire four days from now, however when I test with webpagetest.org it reports this for the image I was checking with:

    Request Headers:

    GET /wp-content/gallery/cache/11__250x_blea_tarn-2780.jpg HTTP/1.1
    Accept: */*
    Referer: http://words.mikefinley.co.uk/
    Accept-Language: en-us
    UA-CPU: x86
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; PTST 2.222)
    Host: words.mikefinley.co.uk
    Connection: Keep-Alive
    Response Headers:

    HTTP/1.1 200 OK
    Date: Tue, 03 Aug 2010 08:28:38 GMT
    Server: Apache/2.2.14
    Vary: User-Agent,Accept-Encoding
    Last-Modified: Thu, 29 Jul 2010 16:36:50 GMT
    Accept-Ranges: bytes
    Content-Length: 21572
    Cache-Control: public, must-revalidate, proxy-revalidate
    Expires: Tue, 03 Aug 2010 16:36:50 GMT
    Pragma: public
    Keep-Alive: timeout=5, max=99
    Connection: Keep-Alive
    Content-Type: image/jpeg

    As you can see, expiry is set four days after the creation date of the image file, not four days after the request, meaning that really old data won’t be cached unless very long expiry dates are set. (I had originally set the expiry time at one day, and was puzzled why nothing was being cached by the browser.)
    Am I wrong in my understanding of how this should work, or is this an error in W3TC?

Viewing 11 replies - 1 through 11 (of 11 total)
  • Thread Starter efikim

    (@efikim)

    13 years, 8 months ago

    (corrected tags)

    Plugin Contributor Frederick Townes

    (@fredericktownes)

    13 years, 8 months ago

    As far as I can see, 4 days was added where appropriate.

    Thread Starter efikim

    (@efikim)

    13 years, 8 months ago

    I’d expected the four days to be added to the access date
    Date: Tue, 03 Aug 2010 08:28:38 GMT
    rather than the modification date
    Last-Modified: Thu, 29 Jul 2010 16:36:50 GMT
    for media files

    This would have given an expiry date on 7th August rather than 3rd.

    As I have images that are over a year old (and may at times be using one of these as the masthead image) this would mean long expiry times for recent media files.

    If this is not the normal requirement I think I can now make the necessary additions to the .htaccess file to get what I want, now your plugin has pointed me in the right direction! Thanks for your help! 🙂

    perennialmind

    (@perennialmind)

    13 years, 8 months ago

    I too expected the “Expires header lifetime” setting to be relative to access time. The fact that Cache-Control max-age draws from this same field reinforced this impression. I actually saw duplicate, incompatible max-age values at one point due to merged headers.

    If this is the intended behavior, I would suggest changing the UI a bit – preferably permitting selection of the alternate behavior. It seems like a strange default though.

    Why

    ExpiresByType image/jpeg M432000

    instead of

    ExpiresByType image/jpeg A432000

    ?

    Plugin Contributor Frederick Townes

    (@fredericktownes)

    13 years, 8 months ago

    As I have images that are over a year old (and may at times be using one of these as the masthead image) this would mean long expiry times for recent media files.

    The problem is that testing showed that various version of apache behaved unreliably when setting this header by modification date. I’ll add an option for users to toggle it. If it breaks your servers, it will be up to you to change the setting. 🙂

    Thread Starter efikim

    (@efikim)

    13 years, 8 months ago

    Thanks Frederick!

    I’d hate to be trying to write something as complex as this and at the same time coping with all the different combinations of php and apache versions and hosting configurations – never mind the odd directory structures some of us come up with 😉

    Plugin Contributor Frederick Townes

    (@fredericktownes)

    13 years, 8 months ago

    That’s just development.

    Pascal Dreissen

    (@pdreissen)

    13 years, 8 months ago

    Frederick,

    I made modifications to the latest development version available (08/11/2010) to select the ExpireByType modification or access time. I think it is more viable to use the access time. Can i submit the modification of the 3 files (/lib/W3/Config.php, /lib/W3/Plugin/BrowserCache.php,/inc/options/browsercache.phtml) anywhere ?

    I am pretty sure you already built this in already 🙂

    Plugin Contributor Frederick Townes

    (@fredericktownes)

    13 years, 8 months ago

    I’m already clear on what to change for this issue, the point remains that more testing is required to ensure compatibility with all versions of apache. That task is in queue.

    miejsca

    (@miejsca)

    13 years, 5 months ago

    Is it updated by any chance?

    Plugin Contributor Frederick Townes

    (@fredericktownes)

    13 years, 4 months ago

    Yes.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘[Plugin: W3 Total Cache] expiry header set incorrectly?’ is closed to new replies.