Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We do not currently use Expire headers, I was going to recommend it but forcing our large development team/business to change their practices and rename static files with each new release isn't going to be easy to get updated files.

I ran YSlow and we get an F for Etags, "There are 24 components with misconfigured ETags". The Apache httpd.conf does not have Etags manually configured so it appears we are using the default settings. (FileETag INode MTime Size). When I visit our site and then hit refresh I can see Etags appear to be working pretty well:

One image example: If-Modified-Since: Sat, 23 Jul 2011 02:05:28 GMT If-None-Match: "21246-eb05-4a8b30415ea00" Cache-Control: max-age=0

HTTP/1.1 304 Not Modified Date: Tue, 06 Sep 2011 20:59:29 GMT Server: IBM_HTTP_Server Connection: Keep-Alive Keep-Alive: timeout=6 Etag: "21246-eb05-4a8b30415ea00"

1) I see a "304 Not Modified" for image files,js,html,etc on our landing page. Why does Yslow say we have some misconfigured Etags when they are all configured with the same default Apache configuration? The YSlow report mentions these same file types..

2) We have an F5 Load balancer between multiple Apache webservers, we use sticky bits which is why I think the Apache inode Etag is not bothering us too much. But if a user comes back tomorrow and hits another webserver we will lose the cache option correct because they indode will be different? Should we change the httpd.conf and remove the Etag inode variable from all webservers?

Sorry for the length! Thanks

share|improve this question

2 Answers 2

up vote 1 down vote accepted

1) Maybe the message is not about static files but other delivered content which doesn't have ETags (e.g. PHP pages, CGI output etc)?

2) Yes, you should remove the inode from the tag and also make sure that the files have the same timestamp on all backends.

share|improve this answer
    
Thanks for the feedback! They are the same file types it seems, I have seen with HTTP Live headers for example both png's and js are getting 304 Not Modified messages on our landing page and two examples YSlow gave from this same page were js and pngs. –  roacha Sep 6 '11 at 22:04
    
One other question on your #2 response above. If all webservers are in sync and inode is removed how long does the image last in cache? Does it just check the file timestamp and size and if it has not changed then it is pulled from cache? If so that sounds better than expire headers to me.. –  roacha Sep 6 '11 at 22:17
    
Yes as long as the file and its attributes stay the same, the ETag stays the same and clients will get 304s for it. Regarding 1), maybe Yslow does it's own fingerprinting/hashing on the files and caught that it got the same file with different Etags because of the inode issue? I agree, a bit far fetched though :) –  C. Ramseyer Sep 6 '11 at 22:32
    
Interesting you might be right, I found the exact same static css file in my LiveHeaders data as getting a 304 Not Modified, GET /static/consumer/consumernet/theme/styles/private/styles.css HTTP/1.1 and this was one of the exact filenames that Yslow mentioned, /static/consumer/consumernet/theme/styles/private/styles.css –  roacha Sep 6 '11 at 22:57
    
Final question I have is why would you use Expire Headers if you can use ETags to check if the file has changed and if not it is served from the browser cache indefinitely. And it also handles the issue with Expire Headers of when you update the file on the server you don't have to change the name. I must be missing something.. –  roacha Sep 6 '11 at 23:00

C. Ramseyer is correct. Here's a config I use to keep YSlow fairly pleased:

<Directory /path/to/files>
  FileETag MTime Size
  ExpiresActive On
  ExpiresDefault "access plus 1 week"
  ExpiresByType text/html "access plus 1 week"
  ExpiresByType text/css "access plus 1 week"
  ExpiresByType text/javascript "access plus 1 week"
  ExpiresByType image/gif "access plus 1 month"
  ExpiresByType image/jpg "access plus 1 month"
  ExpiresByType image/png "access plus 1 month"
</Directory>

Be sure though that you are ok with caching pages for 1 week. If you have a blog for example that's updated daily, the above setting will cause the list of posts to be cached for 1 week. In this case you may want to use ExpiresDefualt "access"

share|improve this answer
    
Thanks Fuscata, so in your example if a user tries to pull a logo.gif and it has not been updated on the server side. Will it just check the Etag value first and if it has not changed pull the image from the browser cache and thus never even look at the expired date? Or does is check the expired date first and if the date is within the 1 month it pulls it from cache ignoring the Etag check? –  roacha Sep 6 '11 at 22:43
    
(tl;dr not sure) I suppose it depends on the browser. You're goal is to help the browser figure out if it needs to download the file; since the browser wants to be as fast as possible, you gotta count on it to do its best, and count on YSlow to hep you do that. BTW: gtmetrix.com –  xofer Sep 6 '11 at 23:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.