posted: March 31st, 2008 · by: Sven
So, Rails has added some great HTTP related features with HTTP authentication, ETagging and, of course, support for REST. These actually greatly help scaling our applications by moving to HTTP what really belongs there.
One similar feature that has been in Rails for ages is page caching which just saves the response to a file and lets the frontend server handle subsequent requests. For example Mephisto is known to be “fast as hell” just because it uses page caching for public, non-authenticated pages.
Unfortunately Rails page caching doesn’t work with authentication: if you have to authenticate your users you simply can’t use it.
For applications that target human users HTTP authentication might be of limited use anyways in many cases because it still opens up that ugly browser authentication dialog box that only die-hard HTTP geeks really like. On the other hand, when it comes to closing down an admin section for a blog, maybe that dialog is still a valid option for certain applications?
Also, these days it seems to be possible to get around that UI non-design with Ajax … so we might even be able to overcome this limitation. (Or maybe it it’s not, like Mislav told me at Euruko. I’d still have to actually try that stuff out. But anyways :)
But even if not, the ability to HTTP authenticate cached pages should be great news at least when it comes to web services that need some authentication but often times don’t need any “personalization” based on user preferences or whatever.
After some recent experiments I really think this kind of stuff is actually possible. And not only that, it’s even very simple to implement it in Mongrel and Rails as a proof of concept (which might not be sufficient for production, but see below).Read the rest of this entry