Charles Miller wrote HTTP Conditional Get for RSS Hackers in response to this burgeoning thread on reducing the hit of RSS polling. It's a good simple explanation, but there's a problem in this part:
Whenever someone requests your RSS file, check the headers of their request for an If-Modified-Since header, or an If-None-Match header. If either of them are there, and if either of them match the values you were planning to send out with the file, then don't send the file.
Unfortunately (and this is what I was saying in my comment in the thread) the HTTP spec says you can't:
If any of the entity tags match the entity tag of the entity [to return], then the server MUST NOT perform the requested method, unless required to do so because the resource's modification date fails to match that supplied in an If-Modified-Since header field in the request. [Emphasis mine.]
So if you get both If-Modified-Since and If-None-Match from the client, and your last modified date doesn't match the If-Modified-Since, you're supposed to send the 200 even if your ETag matches the If-None-Match.
Not as if I really care, and Charles' piece says you should get the Last-Modified date from your most recent RSS item anyway rather than letting the server say it's now for dynamically generated content. If you do what the very fine piece says, your server isn't being totally HTTP compliant.
