-1

I know that there are some differences between GET and POST, like descriped in this post on StackOverflow. But what I cannot figure out is, are they interchangable, assuming that you change your code accordingly?

For instance, could you use POST to request HTML-content and display it in the browser? I am not concerned with whether or not this is best practice, only if it is possible.

Update

I should point out, that POST and GET are two different ways of sending HTTP requests. I am aware of this and I am aware that it does makes a difference which one you use. Especially when it comes to security, it is important to know the difference.

What I basically wanted to know was, if it was possible (from a technical point of view) to use POST instead of GET and vice versa. From the answers in this post, it is clear that this is possible to use either. That does not mean that it doesn't matter which one you use.

Update 2

After much confusion, let me see if I can make this clearer: My understanding is, that all HTTP requests are basically just text strings. Hence the only real difference between GET and POST lies in the interpretaion of that text string. If you changed your HTTP server, you could make it handle GET requests as POST and vice versa. I am aware that this is a horrible idea, with no real usage, I just wanted to know, if my understanding was correct.

Jakob Busk Sørensen
  • 726
  • 5
  • 13
  • 1
    Are you asking if it is possible to rewrite the browser code to use POST by default? – JacquesB Sep 18 '17 at 14:15
  • 5
    Is it possible to GET data by POSTing? Yes. Is it possible to POST data by Getting? No. – Berin Loritsch Sep 18 '17 at 14:19
  • 1
    Basically I was asking what @BerinLoritsch answered. If anyone has more details on it, it would be much appreciated :-) – Jakob Busk Sørensen Sep 18 '17 at 14:21
  • 1
    Could the people who is downvoting, please leave a comment as well. Otherwise it's quite difficult to improve my questions for next time. – Jakob Busk Sørensen Sep 18 '17 at 16:25
  • You can write javascript in the browser or a web request in C/C++/Java/C# to POST to the server to get data. However, you cannot make an ordinary browser use POST by default. Also, proxy servers and other HTTP things expect GET's to be [idempotent and "safe"](http://restcookbook.com/HTTP%20Methods/idempotency/) whereas POST not. – Erik Eidt Sep 18 '17 at 16:57
  • 3
    @Noceo: I'm not the downvoter, but I think if you define what "interchangeable" means that would help. Not a duplicate, but definitely related: [Why shouldn't a GET request change data on the server?](https://softwareengineering.stackexchange.com/questions/188860/why-shouldnt-a-get-request-change-data-on-the-server?rq=1). – Greg Burghardt Sep 18 '17 at 17:12
  • There's the classic example of the very poorly designed website that had delete links as GET. The Googlebot came along and deleted the whole website. – Loren Pechtel Sep 21 '22 at 04:39

5 Answers5

7

Yes given you have control over the server's handling of this. I worked with some java server code that treated both methods as equivalent. In fact, the operation is really just a string that is passed along. You can do a GOST and PET if you like. These are conventions.

While there's nothing about HTTP that prevents this kind of thing, most APIs and/or browsers will not support it.

You say you don't care whether it's a good idea or not but I think it's important to know that mixing these up can create dangerous security flaws. It's crucial that you do not use GET for anything that is not safe. Doing so can open you up to a very easily exploited vulnerability. Specifically, if you have a GET that, for example, logs in a user, simply putting the URL in the src attribute of an img tag will cause it to happen when a page containing that image is loaded. It doesn't need to be an actual image to do this. It's a really bad idea to go against the grain with this kind of thing. It's like driving on the wrong side of the road on an expressway. No good will come of it.

JimmyJames
  • 24,682
  • 2
  • 50
  • 92
  • 1
    Thanks. I am well aware of the security issues, but it's a good point, since other people might not be. My interest in the topic was more academic than practical :-) – Jakob Busk Sørensen Sep 18 '17 at 15:59
4

Yes, but… GET has limitations over POST. Since all of the data is encoded into the URL, …

  • browser and web server specific URL length limits apply (usually around 1 to 4 KB).
  • File upload (<input type="file">) is not possible.
  • All of the content, including passwords, are visible in plain text in the address bar, and browser history.
  • URLs and thus the data is likely to be logged on web servers.
  • The response is handled as the content of that URL and may be cached (i.e., it may be outdated).
  • The URL may be queried several times (like one time by the OS to determine the content type to start the corresponding application, and the application may download the URL again). If the URL causes action on your system, the action will be repeated.
  • Same for page reload and back button clicks.
  • The character set is not explicit in an URL. This may cause additional issues.
Matthias Ronge
  • 507
  • 3
  • 11
3

If you look at the accepted answer on that same question and the purpose behind them, no they are not interchangeable. In fact, your JavaScript libraries won't allow you to send JSON or XML directly to a GET url endpoint.

The intent behind GET is to retrieve data. You can use it to allow searching, etc. However, the intent behind POST is to send data from the client to the server.

To answer the question specifically about whether POST URLs can return results, the answer is yes. There is no technical limitation that prevents a POST call from retrieving information from a server. For better or worse, many document databases with a built in JSON query language behave exactly in this manner.

Now there are further technical limitations based on firewall configurations that you may or may not be aware of, as well as limitations in the JavaScript API layer.

  • Some corporate firewalls that are very concerned about people accidentally spilling company secrets can turn off POST requests at the firewall level. They typically leave GET open, which is why it's not a bad idea to have search boxes accessible via GET. Granted this is a small group of users in the big scheme of things.
  • JavaScript libraries do not allow you to GET with a JSON or XML payload. While "technically" possible for machine-to-machine communications, the majority (if not all) of browser implementers do not allow you to do that.
Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
1

There is a significant reason why GET and POST are not interchangeable.

On websites that use session cookie.

GET requests will include the session cookie on cross-origin top-level navigation when the SameSite attribute on cookies is set to Lax (default value).

POST requests on the other hand, will only include session cookie on cross-origin when SameSite is None.

That means that a click on a malicious website toward your website will result in an authenticated request. That is why GET are meant to be safe and idempotent.

The purpose of this is allowing user to navigate to a website without asking them to reconnect every times.You just click on facebook.com and access the website already logged in.

GET and POST have different purposes by design and interchanging them may expose your application to CSRF.

guboi
  • 11
  • 2
-1

Not to my knowledge, no.

A GET request retrieves information from a website, and displays it in the format that you specify. This is useful for retrieving MI data from websites.

A POST request posts data to the website. A common use of POST is to automate account creation and such like.

Hope that helps :)

Korthalion
  • 119
  • 1
  • 1
    I agree that's how they are usually used (and intended to be used). But what about when you use post in an HTML Form? That redirects you to some URL, defined by `action=`. But is that then a `POST` followed by a `GET`? – Jakob Busk Sørensen Sep 18 '17 at 14:19
  • 1
    Interesting - I see what you mean now! Yes, I suppose you could use a POST request like that, you could use one to in effect automate the process a user goes through to receive information on the website. But using that method to explicitly receive information from a website is contrived at best unless you have no other option. – Korthalion Sep 18 '17 at 14:23
  • 3
    I suppose it's also worth noting that you usually receive information back from the server upon a successful POST. In the example of page/account creation the executor of the request would usually receive login/URL details. – Korthalion Sep 18 '17 at 14:27