Deciphering and interpreting an RFC is never an easy thing and many times the same RFC can be interpreted different ways.  My favourite RFC is RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 specifically section 13 on caching and section 14 on headers make for a very interesting read.  I frequently encounter situations where browsers and applications don't appear to behave as the RFC states they should.  Here are a couple of examples I have come across:

Firefox 3 Expires and Max-Age

According to section 14.9.3 "If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive."  Recent testing with Firefox 3 has revealed that this is not the case.   If the Expires header is in the future then the Max-Age value from Cache-Control header is honoured, but if the Expires header is in the past then Firefox 3 will cache the content on the browser with an immediate expiry. Neither  Internet Explorer 7 nor Chrome exhibit this same behaviour the cache-control headers always override the Expires header even when the value is in the past.   This discrepancy in behaviour when a customer said they were getting inconsistent results during their testing of WebAccelerator, just goes to show the importance of performing cross-browser functional testing of your application.  

Maximum Value for Expires Header

Section 14.21 covers more details on the use of the Expires header specifically appropriate values for the header. 

"HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future."  However I occasionally see headers like the one below that is set for almost 30 years.

Expires    Sun, 17 Jan 2038 19:14:07 GMT

I'm all for setting expires in the future but isn't 1 year sufficient or is 30 years really necessary?

Cache-Control Private

This came to my attention through one of the forum posts on DevCentral in regards to the insertion of a Cache-Control=private header into responses and how this was impacting Akamai.  It turns out that Akamai does not honour the Cache-Control header of private.  Section 14.9.1 of the RFC states a private header  "Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. "  In my opinion Akamai is a shared cache and should not cache content with the Cache-Control header of private. 

These are just 3 examples of how items in the RFC can either be interpreted differently and sometimes ignored.  I'm sure there are others out there.  Do you have any other examples?

Read the original blog entry...