Wandering Thoughts archives

All browsers need a (good) way to flush memorized HTTP redirects

As far as I know, basically all browsers cache HTTP redirects by default, especially permanent ones. If you send your redirects without cache-control headers (and why would you do that for a permanent redirect), they may well cache them for a very long time. In at least Firefox, these memorized redirects are extremely persistent and seem basically impossible to get rid of in any easy way (having Firefox clear your local (disk) cache certainly doesn't do it).

This is a bad mistake. The theory is that a permanent redirect is, well, permanent. The reality is that websites periodically send permanent redirects that are not in fact permanent (cf) and they disappear after a while. Except, of course, that when your browser more or less permanently memorizes this temporary permanent redirect, it's nigh-permanent for you. So browsers should have a way to flush such a HTTP redirect just as they have shift-reload to force a real cache-bypassing page refresh.

(A normal shift-reload won't do it because HTTP redirections are attached to following links, not to pages (okay, technically they're attached to looking up URLs). You could make it so that a shift-reload on a page flushes any memorized HTTP redirections for any link on the page, but that would be both kind of weird and not sufficient in a world where JavaScript can materialize its own links as it feels like.)

Sidebar: Some notes about this and Firefox

I've read some suggestions that Firefox will do this if you either tell Firefox to remove the site's browsing history entirely or delete your entire cache directory by hand. Neither are what are I consider adequate solutions; one has drastic side effects and the other requires quite obscure by-hand action. I want something within the browser that is no more effort and impact than 'Preferences / Advanced / Network / Clear cached web content'. It actually irritates me that telling Firefox to clear cached content does not also discard memorized HTTP redirections, but it clearly doesn't.

If you have some degree of control over the target website, you can force Firefox to drop the memorized HTTP redirection by redirecting back to the right version. This is generally only going to be useful in some situations, eg if you have the same site available under multiple names.

The real speed advantage static rendering has over dynamic rendering

This entry made the Hacker News front page for much of Sunday, spending a bunch of time at #1 (clearly Sundays are slow news days) and giving me another opportunity to beat the drum about my views that dynamic sites don't need to be slow. So today, I'll take the other side and point out the real speed advantage that static rendering has over dynamic rendering.

Put simply, the advantage is that all static rendering is fast while only carefully tuned dynamic rendering is fast. Sure, you can make dynamic rendering go fast on ordinary hardware, and this blog is an existence proof; even with a crazy lashup it runs pretty fast. But you have to work to get fast dynamic rendering, and there are a huge number of ways to get slow dynamic rendering and plenty of software that behaves this way. Slow dynamic rendering is kind of the default state with many setups, software frameworks, system designs, and so on.

By contrast, you have to work really hard to make static rendering go slowly; speed and low impact is its natural state. Pretty much any current webserver with a vaguely rational configuration is going to be really fast at serving static files (especially relatively small ones). I'm not actually sure how you'd make a modern web server do this slowly.

So the default for static rendering is fast and the practical default for dynamic rendering is slow. And this is the real speed advantage; if you pick a random static rendering system to use, you're basically guaranteed to go fast. If you pick a random dynamic rendering system, you're probably going to be slow by default and perhaps fast with some amount of careful investigation and tuning.

(This is also true if you write your own system. A static system is again intrinsically fast on the web server, while you can look forward to paying attention to your dynamic system to make sure you haven't accidentally made it slow.)

Although I continue to feel that dynamic sites have significant advantages (including a more liberal URL design) and are not particularly hard to make fast enough for most people, I have to admit that this is a not insignificant advantage to static sites in practice. Like everyone else, I've heard any number of people be unhappy about how their off the shelf dynamic site is not doing too well under load; say what you like about static site generators, but these people wouldn't be having that problem if they'd used one instead.

PS: Based on a very brief log analysis, the volume from this Hacker News appearance was about the same as the first time around so I don't intend to do a writeup on it. I also suspect that my link experiences are not necessarily a good guide to the amount of traffic that HN directs to its (really) popular links. On the other hand, maybe not.