So get is better for non-secure data, like query strings in Google. Auth-data shall never be send via GET – so use POST here. Of course the whole theme is a little more complicated… who wants to read more, try this: http://bit.ly/gXpgzY

I hope that helped a little.

This little line was taken from my active sync device as it was talking to the server. The rest of the HTTP header followed with the body having some active sync traffic. What do?!

Otherwise a good article, I confess that I have used gets where posts should have been used before…

http://josephscott.org/archives/2009/08/xmlhttprequest-xhr-uses-multiple-packets-for-http-post/

Except for FF, all browsers implement AJAX POST using 2 packets.

Bottom line: all of the browsers I tested except for Firefox will use 2 packets to send this data instead of just 1.

I don’t think it should affect the decision of whether to use GET or POST for the vast majority of cases. Ajax autocomplete is the most performance critical Ajax interaction, and that uses GET already. This might be a consideration for real-time collaboration applications (MobWrite / EtherPad etc) but for everything else I’d stick to the HTTP standard defined rules of which verb to use.

Per RFC 2396, section 3 a URI is defined as:

[scheme] :// [authority] [path] ? [query]

As I mentioned in my first comment/reply “The query string is part of the URI and is NOT passed in the body as per the article.” I am referring to all HTTP Requests, irrespective of method (GET, POST, PUT, DELETE, or other). All HTTP Requests target a URI. Per RFC 2396 (section 3), a URI is defined as: ://?

So all Requests have URIs and all URIs ‘may’ have querystrings, including POSTs. There is no difference between GET and POST as to how the querystring is handled. A POST request’s body is comprised of the name/value pairs of a serialized form element. In order to generate a POST request that contains a querystring separate from the body, create a form where the @action attribute is such: “handler.php?article=DefinitiveGuide”. If you were to inspect the body of this post request via Fiddler (or other) you’ll notice that the body does not contain an ‘article’ key (unless also specified as a form field). This can lead to some interesting server-side code, especially if you have querystring keys colliding with form fields of the same name. PHP makes this even more confusing by naming its querystring autoglobal $_GET which doesn’t neccisarily imply a GET request. Given my previous form example, $_GET would contain a key for ‘article’ and $_POST would contain the fields of the form. See this post on SitePoint regarding GET/POST with PHP in particular: http://www.sitepoint.com/blogs/2009/02/05/on-get-and-post/

I don’t disagree with any other point in your article. I even agree with your security point in GET. As Robert Taylor said “Securing data is a multi-faceted vigil”. Simply preventing browser auto-complete of sensitive information is one (if minor) defense. But I digress…

My only reason for posting is to illuminate yet another misconception regarding GET/POST and the ever lovely querystring.

Feel free to email me or twitter (@jasonkarns) with further discussion.

In reality, it’s always safter to stick with established methods of securing traffic such as SSL (or its successors) rather than trying to implement your own security layer. Unless you’re a real security genius you’re likely to end up making things less secure.