Greetings. Web-server formlets currently send their form input back to the server via an HTTP GET request. They should probably generate a form which uses HTTP POST instead.
There are two problems with using GET for this. 1. If there's any sensitive information in the form, such as a password, then it's very obviously exposed in the URL and stored in logs, which wouldn't be the case if the form contents are in the HTTP request body instead. The latter would provide at least a little bit of obscurity, rather than serious security. This is of course not a great way to do authentication (to say the least), but if one trusts the network or one is talking to localhost, then it's good enough for some applications. The problem isn't just confined to passwords, obviously. 2. HTTP defines GET to be side-effect free, and cacheable. Therefore if there's an intermediary server between the client and the server, and it sees a GET request being made, it is (a) permitted to send a cached version if the URL is one it has seen before, and (b) permitted to make the GET request to the origin server multiple times (for example if there is or appears to be a failure), and send only one response to the client. Either of these might mess up the form-mediated client-server interaction, and there's nothing anyone can do about it. This is probably more of a theoretical problem than a common practical one. POST is not defined to be side-effect free, and is not automatically cacheable. Of course (again), the point of continuation-based forms is that they're functional, just like GET, but many people implement services using GET forms which are intended to have side-effects. Simply defining (and using) a send/formlets/post which is identical to send/formlets but with a [method "POST"] added, seems to work fine, because formlet-process uses request-bindings/raw, which handles both GET and POST requests. Therefore, I think that should probably be the default. Best wishes, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _________________________ Racket Developers list: http://lists.racket-lang.org/dev
