HTTP Caching
In February, Omer Gil described the Web Cache Deception Attack.
A long, long time ago, I wrote some tests using XmlHttpRequest
to figure out how well browser caches behaved, and wrote up the
results.
Chrome is looking at adding support for RFC5861’s stale-while-revalidate, which is really cool. I wrote about the details of SwR when it first became an RFC, but its application to browsers is something that’s a new. Seems like a good time to answer a few potential questions.
One of the changes in Apple’s release of iOS6 last week was a surprising new ability to cache POST responses.
More than ten years ago, I was working at Akamai and got involved in the specification of Edge Side Includes (ESI), sort of a templating language for intermediaries.
In discussing my whinge about AppCache offline with a few browser vendory folks, I ending up writing down my longstanding wishlist for making browser caches better. Without further ado, a bunch of blue-sky ideas;
HTML5’s AppCache mechanism is one confused little puppy. Purporting to be for taking web applications offline — a compelling and useful thing — it’s more often used by performance-hungry sites that want to use it as an online cache.
After designing and deploying Cache Channels, it quickly became apparent that one Web cache invalidation mechanism wasn’t able to cover the breadth of use cases.
Patricia Clausnitzer has kindly translated the Caching Tutorial to Belarusian. Thanks!
A while back we used an absurd amount of reward points from our credit card to get some Myer gift certificates, and on the weekend these miraculously turned into a new TV, the Sony 32EX600.
On a bit of a roll, RFC5861: HTTP Stale Controls has (finally) been published as an Informational RFC.
Thomas Hühn has graciously translated the caching tutorial into German. Thanks!
A long time ago*, the word in high-performance proxy-caching was Inktomi’s Traffic Server. It was so fast it was referred to being “carrier grade” and this could be said without people smirking, and it was deployed by the likes of AOL, when AOL was still how most people accessed the Internet.
A (very) long time ago, I wrote the Cacheability Engine to help people figure out how a Web cache would treat their sites. It has a few bugs, but is generally useful for that purpose.
The caching tutorial is now available in Chinese, courtesy of Che Dong (and apologies for taking so long in linking to it!).
Part of my job is maintaining Yahoo!’s build of Squid and supporting its users, which use it to serve everything from the internal Web services that make sites go to serving Flickr’s images.
There’s a rule of thumb about when a HTTP response can be cached; the Caching Tutorial says:
Ryan Tomayko announces Rack::Cache, a HTTP cache for Ruby’s generic Web API;
The stale-while-revalidate and stale-if-error extensions aren’t the only fiddling we’ve been doing with the HTTP caching model. Now that Squid 2.7 is starting to see daylight, I can explain about a much more ambitious project — Cache Channels.
We use caching extensively inside Yahoo! to improve scalability, latency and availability for back-end HTTP services, as I’ve discussed before.
I’ve been hoping to avoid this, but ETags seem to be popping up more and more often recently. For whatever reason, people latch onto them as a litmus test for RESTfulness, as the defining factor of HTTP’s caching model, and much more.
A while back I wrote up the state of browser caching, after writing a quick-and-dirty XHR-based test page, with the idea that if people know how their content is handled by common implementations, they’d be able to trust caches a bit more.
I occasionally get a question from readers of the caching tutorial about whether to use the Expires header or Cache-Control: max-age to control a response’s freshness lifetime.
The QCon presentation ( slides) was ostensibly about how we use HTTP for services within Yahoo’s Media Group. When I started thinking about the talk, however, I quickly concluded that everyone’s heard enough about the high-level benefits of HTTP and not nearly enough details of what it does on the ground. So, I decided to concentrate on one aspect of the value that we get from using HTTP for services; intermediation, as an example.
There have been some interesting developments in Web caching lately, from a performance perspective; event loops are becoming mainstream, and there are lots of new contenders on the scene.
Many thanks to J.J. Solari for translating the Caching Tutorial to French!
I just finished my XTech presentation, “ Web 2.0 on Speed”. here are the slides [pdf]; I’m going to try to s5 them soon. There isn’t much new in this talk; it’s just a synthesis of a few different observations;
It’s official; I’ve got a last-minute slot at XTech, talking about all things Web caching.
Have you ever posted a comment to a blog, found it missing, so you re-posted it, only to find two entries? Annoying, huh?
The first in an occasional series about the real-world benefits of REST and the Web architecture, as applied to HTTP.
There’s been quite a kerfuffle over Google’s Web Accelerator, because it prefetches Web content.
I happened to look at the HTTP headers returned from Google News just now (what can I say, I’m a HTTP geek), and I noticed something unusual;
I’ve published a revision of the Caching Tutorial for Web Authors and Webmasters, the first non-trivial edit in some time almost since I wrote it in 1998. That said, there aren’t any substantial changes; this is mostly tweaking and incorporation of new information.
If we WebDAV-enable Web applications, people will be able to interact with them like filesystems. To blog something, you’d be able to write an entry in the text editor of your choice, and then drag-and-drop them into what MSFT has called “Web folders.”
I feel compelled to respond to Norm Walsh’s thoughts on caching.
I’m extremely wary about the new prefetching feature in Mozilla. The Web caching community has tried this from about every angle, but the general consensus of professionals (with one notable exception) is that prefetching is a bad approach.
