For over a year, the PLT Web Server has supported stateless Web Servlets via the #lang web-server language. This language compiles the servlet in a special way that allows continuations to be used and serializes them to be stored by the client on their Web browser. This greatly improves performance, with relatively few restrictions.
Unfortunately, it was a major pain to use this language, because the default Web server configuration did not provide a way to serve them.
I have merged the two dispatchers that were responsible for these servlets and traditional servlets. Thus, every Web server configuration that allows any servlets will allow both. This will improve the ease of transition and experimentation for our users. Hopefully with more use, they become even more useful!
Posts
7 comments:
Hi Jay! I'm really glad to hear that you're trying the stateless-server idea. I think that stashing continuations on the server and expiring them is bad mojo for users, since their links can die unexpectedly, and a pain for admins to worry about managing those expiration times.
How did you manage to deal with Scheme's mutable variables? It seems you'd need to serialize a whole store.
Thanks for the interest Ezra.
There is no special consideration for the store. Servlets are free to use it, but if they do, they should not rely on changes being present when the next continuation is loaded. There are, of course, libraries for tying data to files ("file boxes") and database APIs, such as for PgSQL and SQLite.
Hi Jay! Storing continuations on a clients browser sounds interesting. Does the stateless servlet code do anything to make sure clients haven't modified the continuations they're invoking?
In other words I'm wondering if someone could do something to my application by modifying a continuation to make it do what they want before sending it to my web server for invocation.
Thanks!
Hi Ryan,
There are a number of policies stateless servlets can choose. By default, the server is protected from modifications to the continuation by the client. It is possible to relax this restriction.
However, I could imagine it is ill-advised. Anything the client can do, the server can do as well. Are you worried about the additional work (CPU or network) associated with transfer the old continuation and the change instruction? I would be surprised if practical scenarios like this would have prohibitive performance.
I'm worried about the client changing the continuation to take control of the server and using the server for the client's own purposes(insert bad thing here).
How does the server know that a continuation it receives from a client hasn't been tampered with?
It uses very standard cryptographic techniques.
Basically, by using a fast MAC it can guarantee that it hasn't been changed. I've implemented something that is recommended by the MIT Cookie Eaters.
Another, similar technique, is to send a hash to the client and store the continuation on the server. This actually has amazing performance gains, because in garbage collected languages, the OS' virtual memory system is basically useless.
Jay
Thanks Jay!
Post a Comment