YSlow giving inconsistent results on ETags

Question

When I run YSlow against my site, I get an "F" on the "Configure ETags" item; it claims that there are no etags for many (all?) of my images, stylesheets, etc.

However, if I run the test on one of those images directly, I get an A on the etag test. Furthermore, on the Firebug Net panel's Response headers I can see the etag on this item for both the full-page and direct-url versions.

Is there something that I might be doing to cause this weird behavior?

(The URLs I'm hitting are here and here if anyone wants to check for themselves. I wouldn't mind a sanity check to see if it's just my browser that's confused.)

Answer 1

just tried this locally with FF 3.6 and YSlow 2.0.3 (newly released version) and the standalone image Gives a score of "B", citing misconfigured ETags.

The ETag is showing in the header, bith in the FireBug net panel and in the YSlow components panel.

But, this is by design. If you look at http://developer.yahoo.com/performance/rules.html#etags you will see that the default ETags generated by IIS and Apache are not optimal.

For reference, the actual lint rule in YSlow checks the following two regexes:

  apache_re = new RegExp("^[0-9a-z]+-[0-9a-z]+-[0-9a-z]+$");
  iis_re = new RegExp("^[0-9a-z]+:[0-9a-z]+$");

Answer 2

My answer, in regards to IIS 7, is to ignore YSlow's recommendation.

IIS 7 uses a metabase change number of zero when generating the ETag. That's the part after the colon... so the etag will always be something like "5321116d3585ce1:0", where the first part is generated from the last modified file time, and then a colon and the metabase change number.

Starting with IIS 7, Microsoft set that change number to zero all the time, so it will be the same even across multiple web servers. For IIS 5 and 6, you can set it to zero if you want to achieve the same end result:

http://technet.microsoft.com/en-us/library/ee619764(WS.10).aspx

If YSlow is still using a regex rule of iis_re = new RegExp("^[0-9a-z]+:[0-9a-z]+$"); then they're wrong, and it should be rewritten to accept the etag as valid if it ends with :0