Safari 4 preview

I just grabbed the new update to the Safari 4 preview, and I have to say it’s very zippy indeed. I ran SunSpider benchmarks on it and FireFox 3.0.1 on my Mac Pro. Safari 4 is on average 75% faster, but has many results that are in the 200 – 500% range.

This is only measuring javascript performance of course, but that, plus whatever other changes are in S4, translates to incredible speed in daily use. I use the SafariStand extension to remember my open tabs, and I can reopen about 40 tabs in 8 windows in about 3 seconds, including all their content! FF 3 was a huge improvement over 2, but Safari 4 is a different league. This is only a preview, so it will probably get faster still by release.

The integration of the JS debugger is very elegant (Drosera has been rolled in), but I’m still looking forward to the appearance of FireBug for Safari, which someone is doing as a Google SoC project (S4 adds some FireBug hooks too).

All the new CSS funkiness from recent webkit nightlies is there too, and I suspect many an iPhone and widget developer is drooling over them…

Apache mod_rewrite bug still lurks

There’s this enormous apache mod_rewrite bug that I ran into back in 2005, and to my dismay, it’s still there. Long-standing bugs are usually small edge cases that don’t affect many people, but this one is a monster that I suspects pretty much everyone that’s using mod_rewrite, and they’ve just been lucky in avoiding it. The basic issue is this: if you match params that require URL encoding to be safe, mod_rewrite will not rewrite the back-reference (that’s $1 below) correctly. So take this very simple redirect:

RewriteRule ^(.*)$ index.php?show=$1 [R]

so you hit http://www.example.com/a%2Fb and mod_rewrite neatly rewrites it as http://www.example.com/index.php?show=a/b! Notice that it has urldecoded the matched parameter in the replacement string.

Apache 2.2 introduced a new B flag to deal with this, but that apparently suffers the same problem! There are two workarounds I’ve used that are both horrible: double-encode the source string (if you are in control of both start and end points of the URLs) to survive the spurious urldecode, or base-64 encode (javascript flavour) it and do the decoding yourself. I did warn you they were horrible.

I’ll bet that there are a zillion mod_rewrites out there that suffer from this fundamental problem and haven’t even noticed. If a few people voted for this to be fixed, it would probably go away…