GET vs. POST

I promise, this gets funnier.

When one develops a web form, like the MrPikes Contact Form, one chooses the means by which the form data will get from the user’s browser to the program on the web server that *does* things with that data – like sends an email, or writes a record to a database. One’s choices are GET or POST.

The GET method encodes the form data into the URL. If the MrPikes Contact Form used the GET method, the resulting URL would look something like this:

https://www.mrpikes.com/contact.php?name=Max%20Mosley
&email=max.mosley%40fia.com&subject=Stop%20Heckling%20Me
&message=You’re%20hurting%20my%20feelings.
&human=20&submit=Send+Form

You tend to see long, ugly URLs like this on sites that dynamically nail their pages together based on database queries.

The POST method passes the form data to the web server in a way that is invisible to the user, i.e., the values are not encoded in the URL.

Each method has its advantages and disadvantages, but the rule that I always follow is that if a user input the data, always use POST.

This is to prevent URL hacking, which amounts to replacing values in the URL manually, with potentially devastating security implications.

It can also be hilarious.

CNN has a beta program which enables visitors to create t-shirts from headlines, available for purchase. The developers went with GET, meaning that users can hack the URL and make t-shirts that say whatever the hell they like. Since the program is still in beta, you cannot actually order the t-shirts, but that hasn’t stopped Gawker, Fark and numerous other sites from having a field day with the program.

My own contribution:

It's Raining Men. Hallelujah.

One thought on “GET vs. POST

  1. Nice there, boy-o – I personally like this one: “Half-eaten Obama waffle goes up for bid” – it’s on a shirt, so it must be true.

Comments are closed.