Twisted Whisper
Twisted Whisper

Reputation: 1196

Response.Redirect is performing POST instead of GET

I have a LinkButton on my page and when it is clicked, the normal behaviour will postback to the same page (you can tell the page was POSTed by refreshing the page hitting F5 and you will get a confirm box from the browser "The page you are looking for used information that you entered. Returning to the page might cause any action you took to be repeated. Do you want to continue?")

So in order to prevent users from resubmitting processed forms, I decided to response.redirect it to the same page.

void LinkButton1_Click(object sender, EventArgs e) {
    Response.Redirect("Default.aspx"); //redirecting back to the same page
}

As far as I'm concerned, a Response.Redirect should be using GET, but in this case it is using POST (after the redirect, a F5 refresh will still prompt me if I want to resubmit the form). I suspect that the Response.Redirect was not executed so I changed the url from "Default.aspx" to "HelloWorld.aspx" which is located in the same server same directory and it redirected properly. Hitting F5 now will instantly refresh the page without asking me if I want to resubmit the page.

What gives? I have other codes on my page but I doubt they caused this behaviour and they're too long to be posted here. If need be, I'll furnish it. Thank you for your time reading this.

Upvotes: 2

Views: 3786

Answers (2)

Sean Osterberg
Sean Osterberg

Reputation: 844

Are you using Chrome? The Post/Redirect/Get pattern appears to be broken, resulting in the "Confirm Form Resubmission" dialog even if a Response.Redirect() is issued: https://code.google.com/p/chromium/issues/detail?id=21245

Second, Response.Redirect() always works like this, using Default.aspx as an example:

  • Open page
  • Client: HTTP GET Default.aspx
  • Server: HTTP 200 Ok
  • Enter form data, press submit button
  • Client: HTTP POST Default.aspx
  • Server: HTTP 302 Redirect to Default.aspx
  • Client: HTTP GET Default.aspx

I created a sample ASP.NET app with a form, then added a LinkButton with an event handler that calls Response.Redirect(Request.RawUrl), which by the way is preferred over something like Response.Redirect("Default.aspx") because it uses relative paths for the calling page and works in development and deployed environments.

In IE, after entering data into the form and pressing Submit, then pressing F5, I didn't get a "Confirm Form Resubmission" dialog. Same with Firefox; no dialog. But in Chrome, I did receive the warning. My only conclusion is that you might be hitting the Chrome issue.

Upvotes: 3

Brian Webster
Brian Webster

Reputation: 30855

What is Happening

I have noticed this issue in Chrome, but not Firefox or IE.

In fact, Chrome is performing a GET, but it is tying the POST and the GET together -- I suppose there is some optimization involved.

You can confirm this behavior by hitting Ctrl-F12, viewing the network tab. Note that there will be a 302 POST AND a 200 GET.

I do not understand exactly what Chrome is doing, as the debugger shows a 302 followed by a GET, yet the refresh clearly prompts about form re-submission.

Information Conflict

There is severe misinformation regarding 302 redirects on the Internet, especially on Stack Overflow.

Historically, most browsers have converted POSTs to GETs when encountering a 302 redirect.

However, according to the standard, a POST should stay a POST, and a GET should stay a GET (Source). Despite this, most browsers continue to convert all 302's to GETs.

They probably do this because the typical browsing experience is more annoying with all the extra form re-submission dialogs. It's probably faster browsing too.

How to Fix It

A 303 redirect is the proper way to redirect the application after a POST.

Response.Clear();
Response.Status = "303 See Other";
Response.AddHeader("Location", "MyNewURL");
Response.End();

All browsers will behave consistently if you use this method, as browsers must use GET for the new URL.

References

Upvotes: 3

Related Questions