Create an Account
username: password:
 
  MemeStreams Logo

HTTP Caching is bretarded: Or, how I learn to stop worrying and accept that 'no-cache' actually does cache.

search

Acidus
Picture of Acidus
My Blog
My Profile
My Audience
My Sources
Send Me a Message

sponsored links

Acidus's topics
Arts
Business
Games
Health and Wellness
Home and Garden
Miscellaneous
Current Events
Recreation
Local Information
Science
Society
Sports
Technology

support us

Get MemeStreams Stuff!


 
HTTP Caching is bretarded: Or, how I learn to stop worrying and accept that 'no-cache' actually does cache.
Topic: Miscellaneous 12:47 am EDT, Aug 24, 2008

HTTP Caching is now added to my growing list of things that are Bretarded.
Behold RFC2616:

no-cache

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.

In other words, HTTP responses with a no-cache directive will actually be cached by downstream web caches. However when subsequent requests for that resource come into the cache, the cache must send a conditional GET to the original web server to check if the response it has cached is ok to serve.

So no-cache actually means cache, but revalidate.

... ok... so what about the must-revalidate directive?

must-revalidate

Because a cache MAY be configured to ignore a server's specified expiration time, and because a client request MAY include a max- stale directive (which has a similar effect), the protocol also includes a mechanism for the origin server to require revalidation of a cache entry on any subsequent use. When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. (I.e., the cache MUST do an end-to-end revalidation every time, if, based solely on the origin server's Expires or max-age value, the cached response is stale.)

Great, so must-revalidate actually means the cache must send a conditional GET to the original server to revalidate the cached respoinse, but only if that response is stale. IF the cache still thinks the response is "fresh" it can serve a cached response regardless of the "must-revalidate" header.

Welcome to the fucked up world of HTTP caching! Of course, all this craziness is based on the premise that User-Agents can tell caches to give them stale resources. Which was probably a fairly bad idea in the mid-90s "the web is a series of static documents connected by hyperlinks" view of the world, and is an utterly horrible idea in the Web 2.0 view of the world.

There are absolutely no good comprehensive resources that explain HTTP caching directives, cache hierarchies, resolving HTTP/1.0 and HTTP/1.1 directives, etc. Where is a 96 page $39.99 O'Reilly book when you need one?

HTTP Caching is bretarded: Or, how I learn to stop worrying and accept that 'no-cache' actually does cache.



 
 
Powered By Industrial Memetics
RSS2.0