I'm finally just now understand caching header directives. But a few things still confuse me. Firstly here is my setup...
- I parse css and js files with PHP. - I have session.auto_start on in my httpd.conf - I realized the session auto_start sent anti-caching headers so i turned off the auto_start for css and js files. - I want css and js files to cache for 1 month so i do "ExpiresDefault A2592000" for them. This sends the appropriate "Expires" and "Cache-Control" headers. - FYI: no "ETag" or "Last-Modified" headers are sent with css and js files
The first thing I notice is that according to firebug, css and js are never being pulled from the cache, a request is always sent to the server. any ideas why?
Next, I notice that my images ARE caching. They are not being parsed with PHP and they have ETag headers present. In this case a request is still sent to the server, but the server realizes the file hasn't changed and returns a "304 Not Modified" header with no file. Apache won't send an ETag header with a file parsed with php (i know they now have a directive to control this but i'm not at that apache version yet). So using PHP I sent a custom made ETag. Since it wasn't made the same way apache would, I also had to create my own test script to decide whether to send the "304 Not Modified" header. Supposing I could generate the same ETag apache would, would apache automatically return the 304 header for me?
I notice that in the REQUEST sent to the server this header is present Cache-Control: max-age=0 does that mean i'm not setting the servers response Cache-Control header correctly?
The first question is: why you are parsing CSS and JS files with PHP? Do you really need to? Apache handles static content very well, once you add PHP into the mix things become much more complicated.
If you absolutely have to parse the files with PHP, then try cgi_buffer [mnot.net] (I've not tested it though).
As for the response, it looks OK at first glance - you can test with REDbot [redbot.org]. I'm guessing that Apache won't ever natively send a 304 not modified response as it does not itself generate the ETag in your example.
But again, why go through this trouble? There must be a better solution to whatever problem you are trying to resolve with PHP-parsed CSS/JS files. There's no apparent logic to the approach that I can see, because if the file has variables managed by PHP for each request, then how can you cache it for a month? If the file is static, then why let PHP parse it?
I use PHP for a couple reasons. One being that i can make them easier to update. I'll set a variable for font size that i can echo in multiple places. Then i can Divide that number by 2 and use it for paddings.... stuff like that. Another reason is so i can use PHP to check browser type and version and conditionally output stuff. I also use a PHP class to handle colors. And finally I use php to stitch all my individual css files into one. That makes it faster loading and I can easily alter the configuration of a site with a master config file instead of unnecessarily outputting unused styles.
I HIGHLY recommend doing this if possible. Luckily i have 100% control of my server. Even if I can't get them to cache properly... it's worth it with the million headaches it solves.