Francis Hwang wrote: > GETs and POSTs are defined to be fairly different actions. I'd read > http://www.w3.org/DesignIssues/Axioms.html, which is stated to be Tim > Berners-Lee's personal opinion, but I suspect is fairly close to how > many others in the HTTP standards community see it. GETs are for > requests that will not change the resource in question (and can be > safely bookmarked), POSTs are for requests that will change something > (and should not be bookmarked). <snip/> I agree with Francis' point, and dislike the mixing of get and post semantics in the same request. It seems that if the request method is POST, then one should not expect to find the same data structures and data as if the request method were GET. In the case of a POST request, the "query string" is no more than a segment of a funky URL; it only functions as a parameter set when calling via GET. I can see how it could be useful to mix the two, but it strikes me as a bad hack, something that inexperienced Web developers started exploiting when they found that their language of choice allowed this. I understand wanting to help out people migrating to Ruby, but they are going to encounter a number of things that are just plain different (at least I hope that's the case). In general, I find arguments by language comparison unpersuasive; saying that PHP allows for something is not terribly compelling. PHP allows for all sorts of things I hope never to see in Ruby. Allowing multiple param hashes is perhaps a reasonable option, provided that the default hash adheres to whatever RFC (or equivalent) applies. For example, if I try to mix post and get (so to speak; browsers only do one or the other), and make a post request, and inspect the default params hash (as apposed to post_params or get_params), I would not expect to see any so-called query string data in there. The QUERY_STRING variable is undefined in a POST (I think; this is my argument at least); there's just the target URL, which may or may not just happen to have ampersands and equal signs in it. Those who like the option of mixing the two would still have the choice, distasteful as that may be. (Of course, they have have the choice now, as hand-parsing the path info from a post URL is pretty trivial; adding it in as a feature is just a freebie. Probably something that belongs in a 'php.rb' module. ) James http://mirrors.webthing.com/view=Noframes/www.w3.org/2001/tag/doc/whenToUseGet.html http://www.htmlhelp.com/faq/cgifaq.2.html#8 http://cgi-spec.golux.com/ncsa/forms.html