First of all, the entire discussion of when GET is appropriate
versus POST is pretty irrelevant to my issue with cgi.rb --
I should, of course, acknowledge that 'idempotent' is a pretty
cool word to be able to use in a sentence. :-)

Plus, please note that that Berners-Lee document is dated 1996,
for Pete's sake.

Let me respond to a few of James's comments.

> 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.

Actually, in all cases the query string is just a funky URL. It
works as a param set in GET because that was found to be a
nice hack for passing params to a requested file. It's just a
way of saying, "Give me abcdef.file, and by the way, give it
to me with asdf=true and qwer=6. Thanks."

> 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.

One man's bad hack is another's brillant discovery -- like using
invisible table for Web page layout -- or say, adding a 'query
string' to pass params to a requested remote file. :-) 

And the idea that the multitudes of Web programmers around the
world who are using both query string data and form data in page
POSTs with PHP or ASP are just a bunch of 'inexperienced' rubes
-- that's not only patronizing, it's plain silly. Just because
one finds it personally "icky," that does not necessarily mean
that people who do it are dolts, or 'wet behind the ears.'

Let me try to make it a bit more clear why including query
string data in the default param list with form POST vars is not
just some dirty little hack, but is a commonsensical approach
(and in the Web programming milieu, the one that I think makes
the most sense) to creating a Web app.

In a Web application, it is common for the user to request
a page with an initial GET to load a blank form, and then
POST it for processing. (Note too that the default "action" for
a Web form is the same URI (i.e., "myself")). Lastly, if there
are errors on the POST, the orignal page has to be reloaded for
the user with her original form values filled in and some kind
of error message or highlighting to indicate what she did wrong.

Rather than having a Web app comprising a bunch of disparate
single files, I have pages assembled from various components,
based on parameters passed to the server in the initial
request. When I POST the form, I have to be able to tell the
server what combination of parameters created the form that
the user has just POSTed -- that also tells me how to process the
form.

> 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.

Looks like somehow I gave the impression that I think cgi.rb
should add features simply because PHP has them. Let me try to
be a bit clearer about why I was mentioning features in both
PHP and ASP. These are probably the most widely used languages
designed specifically for Web-based programming. So it would
seem to me to make pretty good sense to mention the features
in those languages which are specific to HTTP requests when
discussing the functionality of Ruby's default Web-based
programming library.

> 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.

Actually the query_string var is populated correctly with data
on a POST -- Originally I was parsing out the variables from
there, before I decided to have a look at cgi.rb. That's what
makes it sillier: the data is there -- so why leave those params
out of the default hash simply because the method was changed
to POST?  It's like Nigel Tuffnel with that Les Paul guitar
in the Spinal Tap movie -- "Don't even look at it!!!" Would
you reasonably expect the cookies to vanish because you used
changed the request method? So why should query string data?

> Those who like the option of mixing the two would still have the choice,
> distasteful as that may be.

What seems gross and nasty to some people (like kissing girls
is to elementary school boys) is actually quite pleasant and
agreeable to others. I hope the functional descriptions above
make it a bit clearer why it's useful or even necessary to
have URI information along with the POSTed form data when working
in a Web-app environment.

> (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. )

I'm trying to figure out if this is supposed to be genuinely
funny, or sarcastically cutting, or what. Can anyone help me
out here?

I need to stop here, as it's already getting late, and I figure
I've likely bored/annoyed everyone enough with all this. I would
love to hear more thoughts on this.

Thanks.


Matthew