Possible reasons for a browser executing GET rather than post

Question

One of our most common error situations in a web application is that a user executes a GET request where the form should have submitted a POST.

I realize that the most likely case is that they got to the page (by way of a POST) and then clicked in the address bar and hit enter.

The question is, are there other less obvious ways that this could happen (print previews/back button, etc)?

We have never been able to consistently repeat the problems. The problems for different users and different pages nor do they happen very often (maybe once a week).

EDIT: There is no data submitted with the GET request and therefore the processing page crashes out.

Answer 1

Wrong, the most obvious reason why you get a GET instead of a POST is that because you're doing a GET instead of a POST.

A less obvious reason is you forgot to specify method="post" in one of your forms. The HTML standard specifies that the default method is GET, so if you want to POST, you must specify method="post" explicitly.

Scrutinize all of your tags and make sure all of them explicitly specify method="post".

EDIT: When you click on the address bar and pressed enter, yes it's true that the browser will GET a page, but your form wouldn't be submitted that way since the browser treats the URL similar to how a copy-pasted URL would be: a new session without any additional information sent to the server (except cookies).

Answer 2

As you said your problem is intermittent, so having a problem in form method set as get instead of post can be overruled but yes you are right, that if user presses enter in address bar it would be a get request and back button request always depends upon the last request made, if it was a post then any good browser will prompt you about resubmission and if it was get then no prompt, page will be bought back(may be from cache).

May be you can use Firebug (track requests in .net tab)or Fiddler and do some tests with different users/pages if you can reproduce it, its simply pressing enter in address bar.

Edit: And also get is always supposed to 'retrieve information' so if browser is missing something or need something it will be a get but again check in IIS log for those get requests and try them in browser,if they contains query string for viewstate and eventvalidation, then they are really mis-formed request from post to get, if form method is not explicitly set to get.

Answer 3

I believe that an answer to the question "what are reasons for a browser executing GET rather than POST" does not help to solve the problem of receiving a GET on a form where you expect the a GET. But: To answer that question I would simply say that you receive an GET because the browser sends an GET and you can send a GET on any page where you can send a POST. On the other hand, if the user uses the form the browser sends a POST. Thus your server has to be prepared to handle the GET and it should handle the GET in the same manner as a POST with invalid parameters. My suggestion:

• If you receive a GET, display the form again.
• If you receive a POST with invalid data, display the form again and notify the user that he has to enter the data in a specific way.

Maybe a trivial answer, but that's what I would do. Don't know if it adds to the discussion.