According to Sam Ruby, WordPress (among others) isn’t responding as expected to being sent If-None-Match and/or If-Modified-Since HTTP headers.

I’ve tried replicating the experiment with WordPress 2.0.2, 2.0.2 and 2.0.4 — they all yield the same results:

> HEAD http://planet.sfit.dk/feed/
...
ETag: "1a0c3e00da9d1d0a6e145168720f8574"
Last-Modified: Thu, 23 Nov 2006 01:20:07 GMT
...

> HEAD -H 'If-Modified-Since: Thu, 23 Nov 2006 01:20:07 GMT' http://planet.sfit.dk/feed/
...
Status: 304 Not Modified

> HEAD -H 'If-None-Match: "1a0c3e00da9d1d0a6e145168720f8574"' http://planet.sfit.dk/feed/
...
Status: 304 Not Modified

> HEAD -H 'If-Modified-Since: Thu, 23 Nov 2006 01:20:07 GMT' -H 'If-None-Match: "1a0c3e00da9d1d0a6e145168720f8574"' http://planet.sfit.dk/feed/
...
Status: 304 Not Modified

> HEAD -H 'If-Modified-Since: Thu, 23 Nov 2005 01:20:07 GMT' -H 'If-None-Match: "1a0c3e00da9d1d0a6e145168720f8574"' http://planet.sfit.dk/feed/
...
Status: 200 OK

> HEAD -H 'If-Modified-Since: Thu, 23 Nov 2006 01:20:07 GMT' -H 'If-None-Match: "1a0c3e00da9d1d0a6e145168720f8579"' http://planet.sfit.dk/feed/
...
Status: 200 OK

This seems to be working fine, or at least according to plan.

I originally suspected the reason Sam and others were getting it wrong was the use of double quotes in the ETag value, but on the other hand I can reproduce the problem with the feed from webstandards (apparently running version 2.0.2), so it seems the problem might be related to something specific to some sites, not to WordPress itself.