I’ve been messing with Rails when trying to set up a server with a web service and a controller that consumes that web service. Actually, that’s not easy at all, as the controller times out when calling the web service. It should have worked if the web service was remote.

So the thing is that requests are queued (didn’t know that), and therefore it seems that you can’t perform a recursive request (a controller that calls a URL in its own server). Anyway, you can deploy two servers, such as here, where it’s also mentioned that a trick editing concurrent connections should make it work.

EDIT: I’ve checked Mongrel’s FAQ. It seems that Mongrel is actually concurrent, in the sense that a new thread is created whenever a connection is accepted. I suppose that recursive requests are not possible due to dispatch guarding in the server, though I’m not sure why a new thread isn’t created for child requests in that case. To make all this work in a single server, you just have to include:


in your environment.rb. And then, pray (as it’s unsafe to allow concurrency).


Semantic webI’ve been searching for initiatives to add semantics to RESTful web services. (Big) Web services are too complex and thus haven’t been widely adopted by average developers, as it’s arguable that it’s worth its complexity. RESTful web services seem a simple and smart alternative, and I wonder if it can be a boost for semantics. A post at The Sun Babelfish Blog describes how RESTful semantic web services could be.

Resource Oriented Architectures (ROA) focus on resources (each resource has a URI). Following REST principles, each resource has a uniform interface, which is determined by the HTTP operations (CRUD = PUT, GET, POST, DELETE). As a result, the importance is held on in the relations among resources. Typically, semantic web services define, among other things, the operations that are made by a service. In a REST architecture, these operations are known and are the same for all resources, so maybe a different approach should be used.

Cookie monster

I’ve been taking a glance at Rails 2.0 new session storage. Hongli points out in his blog that cookies are not stored anymore as files in Rails 2.0. This makes the design more RESTful, as long as no state is kept in the server side.

Instead, all the session data is supplied by the client in the cookie. How? The session data is validated with a checksum that is generated using an application password.

This implies that session data is public, though it can’t be changed as long as the application password is kept secret.

We are subject to brute force attacks and session replay attacks. There’s currently a flaw that makes brute force attacks easy, although it should be fixed soon.

Also, I have to point out that before I read his post I ignored that all cookie-based session stores were subject to session replay attacks, and the only solution is communication encryption through, e.g., SSL.

Kick off!


This is my first post, the one that nobody might read… However, I’ll take the chance to welcome everybody. 🙂

Mainly, I’ll focus on web 2.0 apps and things, especially Ruby on Rails based. If you’re a web developer and still don’t know what Ruby on Rails is, take a look at http://www.rubyonrails.org, as it might change the way you’ve coded to date!