Semantics of GET and POST Considered Harmful

[Mark Baker]

> I have just demonstrated real-world examples of people using POST as
> GET. Let me now demonstrate real-world examples of people using GET as
> POST.

You're still completely missing the point.  People are free to try to
do POST over GET, and GET over POST.  Even if every developer on the
planet did this, it doesn't change the fact that GET is special because
its use is implicit whenever it's posted on a billboard or written on a
napkin.  It will only cease to be special when some other method
becomes the "thing that is invoked" when it's typed into a browser -
or that it's no longer sufficient to advertise an URL, but that you have
to list it alongside the method with which to access it.

As for legality, and to address Russell's point, RFC 2616 is not
prescriptive about accountability (only the law can be), just advisory.
Of course, I don't believe it's yet been tested in court, but it seems
like a no brainer to me.

> Lets say I am at whois.org, using their GET form and, my lucky
> day, sdfjksadflkjsdf.com is available.
> 
> Now how am I to know what they did with that info on the server-side?
> Maybe they logged it, maybe they didn't. But _now_ look. They have
> given me one of those handy-dandy clickable URL thingies with all the
> info I need embedded right there in the query string, so its a GET,
> but as I'm using it, I'm registering a domain name, so I'm changing
> state.

So if I sent you this URL in email (and you didn't know what you
described above), and you typed it in to your browser, would you
expect to pay the bill?

Like Roy, I don't know how else to explain this without repeating
myself.  Barring any new arguments, I'm out too.

MB