There's not much to explain. In both of them the parameters are sent in plain text in the HTTP request - just in a different part of the request. If you can intercept/fake/tamper with one of them, it's no more difficult to do it to the other.
I, too am curious about how POST and GET are equally insecure. If I'm not mistaken, when TLS is active, the body (headers, cookies, POST contents, etc.) are encrypted, but the URL cannot be because otherwise it wouldn't be routable.
As far as speed goes, a GET request is generally going to be physically smaller, so it will take less time to deal with. But that's only the tip of the iceberg. A get request that kicks off a major server-internal operation is going to lose that edge, and the size of the response is potentially the same for both GET and POST. So picking one over the other for performance reasons alone is a waste of time.
An IDE is no substitute for an Intelligent Developer.
user entered information is append to the url in a query string can only send limited amount of data
the size of the character is sending doget method in the get request will go through the header thats ways its limltation
postmethods requests user entered information is send as adata(not append to url) can send any of data in post the request will go through the body
Tim Holloway wrote:I, too am curious about how POST and GET are equally insecure. If I'm not mistaken, when TLS is active, the body (headers, cookies, POST contents, etc.) are encrypted, but the URL cannot be because otherwise it wouldn't be routable.
Actually, the ENTIRE URL should be encryptable, and not just the query string. In any event, for full routability, you need the port number in addition to the hostname or IP address. Technically, you also need the context part of the URL, but I'll assume that the appserver has decrypted the data stream by that point.
The reason why (in theory) even the protocol/hostname/port should be encrypt-able is because the actual tcp/ip network communications protocol carries the IP address and port number in the packet header. If the destination port is set up for TLS (like port 443 and 8443 usually are), then the payload can be fully encrypted, including the GET command string. I think the plaintext hostname in the sample dump isn't actually part of the encrypted payload, but I'm too lazy to pull out tcpdump and verify it.
GET sends data in name vale pair ,POST uses a Stream,GET is More fast but not secure,
GET method can carry only 1024 bit of data ,i dont know exactly, but i am sure it can carry limited amount of data.
singh gaurav wrote:GET sends data in name vale pair ,POST uses a Stream
This is not accurate. GET params are encoded as name/value pairs on the query string, but POST can also be name/value pairs encoded into the body. In fact any textual data can be sent in the body, not a "stream" (whatever that means). The body could be XML, could be JSON, could be the Base64 encoding of a binary blob -- just about anything that's text.
GET is More fast but not secure,
Once again, GET is not "more fast". Any processing differences between a GET and a POST sending the same amount of data and processing the same way on the server will be completely trivial.
GET method can carry only 1024 bit of data
That actually depends upon the browser.
Joined: Mar 28, 2010
@Bear Bibeault.... It may be possible ...i answered here in a layman terms ...and i suppose whatever i am saying here is true ...
consider this one "Now i can control a air craft ,a ship, fighter plane, a F1 car , a bus , metro train, super fast bullet train and all other many more things " by using my mobile phone in a single time instance but i need to update my mobile ..............
what it means ... in the same way you can secure a GET method / can send a xml/ or send name value pair via Post method...but you have to do a lot of complex implementations ,,,,,,,,,,,,,,,,,,,,,,,, hope you got my point ... and i am not expecting such type of comment from a very respected and a experience person....
singh gaurav wrote:and i suppose whatever i am saying here is true ...
Sorry, no, There were factual errors in your post.
You stated that GET is faster than POST. Not true. It all depends on what the requests are doing, and if they are doing the exact same thing, the processing time will be so close as to be considered the same.
You stated that GET is not secure. POST is also not secure. No request is secure simple based upon the choice of method. Requests are secure by using SSL.
You stated that POST uses a "stream" while GETs use name/value pairs. POSTs store a text block in the body (which can be name/value pairs) not a s stream. Perhaps you are thinking about how the Servlets API allows you to read the POST body using a stream, but the content of the POST body is just text.
I'm sorry if it makes you feel bad to be corrected, but what you posted was not accurate and could be misleading to the novices in the audience.
The difference between GET and POST is not so much about security, but about idempotence. Take a look at what HTTP creator Tim Berners-Lee has to say about GET and POST - http://www.w3.org/Provider/Style/Input.html .
In preparing for battle I have always found that plans are useless, but planning is indispensable. -- Dwight D. Eisenhower