Response.Redirect with POST instead of Get?

Question

We have the requirement to take a form submission and save some data, then redirect the user to a page offsite, but in redirecting, we need to "submit" a form with POST, not GET.

I was hoping there was an easy way to accomplish this, but I'm starting to think there isn't. I think I must now create a simple other page, with just the form that I want, redirect to it, populate the form variables, then do a body.onload call to a script that merely calls document.forms[0].submit();

Can anyone tell me if there is an alternative? We might need to tweak this later in the project, and it might get sort of complicated, so if there was an easy we could do this all non-other page dependent that would be fantastic.

Anyway, thanks for any and all responses.

Answer 1

PostbackUrl can be set on your asp button to post to a different page.

if you need to do it in codebehind, try Server.Transfer.

Answer 2

If you don't have any large data to submit, consider storing the data in a session variable or two and then you can retrieve it on the next page.

Even if there were many fiends in the form, you could put them all into a simple structure and then just store the structure in the session.

Answer 3

Database, do a traditional redirect, use a central db to transfer data between the 2 pages, whether its session in db, or just plain old tables

Answer 4

I suggest building an HttpWebRequest to programmatically execute your POST and then redirect after reading the Response if applicable.

Answer 5

HttpWebRequest is used for this.

On postback, create a HttpWebRequest to your third party and post the form data, then once that is done, you can Response.Redirect wherever you want.

You get the added advantage that you don't have to name all of your server controls to make the 3rd parties form, you can do this translation when building the POST string.

string url = "3rd Party Url";

StringBuilder postData = new StringBuilder();

postData.Append("first_name=" + HttpUtility.UrlEncode(txtFirstName.Text) + "&");
postData.Append("last_name=" + HttpUtility.UrlEncode(txtLastName.Text));

//ETC for all Form Elements

// Now to Send Data.
StreamWriter writer = null;

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);
request.Method = "POST";
request.ContentType = "application/x-www-form-urlencoded";                        
request.ContentLength = postData.ToString().Length;
try
{
    writer = new StreamWriter(request.GetRequestStream());
    writer.Write(postData.ToString());
}
finally
{
    if (writer != null)
        writer.Close();
}

Response.Redirect("NewPage");

However, if you need the user to see the response page from this form, your only option is to utilize Server.Transfer, and that may or may not work.

Answer 6

@Matt,

You can still use the HttpWebRequest, then direct the response you receive to the actual outputstream response, this would serve the response back to the user. The only issue is that any relative urls would be broken.

Still, that may work.

Answer 7

Here's what I'd do :

Put the data in a standard form (with no runat="server" attribute) and set the action of the form to post to the target off-site page. Before submitting I would submit the data to my server using an XmlHttpRequest and analyze the response. If the response means you should go ahead with the offsite POSTing then I (the JavaScript) would proceed with the post otherwise I would redirect to a page on my site

Answer 8

Doing this requires understanding how HTTP redirects work. When you use Response.Redirect(), you send a response (to the browser that made the request) with HTTP Status Code 302, which tells the browser where to go next. By definition, the browser will make that via a GET request, even if the original request was a POST.

Another option is to use HTTP Status Code 307, which specifies that the browser should make the redirect request in the same way as the original request, but to prompt the user with a security warning. To do that, you would write something like this:

public void PageLoad(object sender, EventArgs e)
{
    // Process the post on your side   

    Response.Status = "307 Temporary Redirect";
    Response.AddHeader("Location", "http://example.com/page/to/post.to");
}

Unfortunately, this won't always work. Different browsers implement this differently, since it is not a common status code.

Alas, unlike the Opera and FireFox developers, the IE developers have never read the spec, and even the latest, most secure IE7 will redirect the POST request from domain A to domain B without any warnings or confirmation dialogs! Safari also acts in an interesting manner, while it does not raise a confirmation dialog and performs the redirect, it throws away the POST data, effectively changing 307 redirect into the more common 302.

So, as far as I know, the only way to implement something like this would be to use Javascript. There are two options I can think of off the top of my head:

1. Create the form and have it's action attribute point to the third-party server. Then, add a click event to the submit button that first executes an AJAX request to your server with the data, and then allows the form to be submitted to the third-party server.
2. Create the form to post to your server. When the form is submitted, show the user a page that has a form in it with all of the data you want to pass on, all in hidden inputs. Just show a message like "Redirecting...". Then, add a javascript event to the page that submits the form to the third-party server.

Of the two, I would choose the second, for two reasons. First, it is more reliable than the first because Javascript is not required for it to work; for those who don't have it enabled, you can always make the submit button for the hidden form visible, and instruct them to press it if it takes more than 5 seconds. Second, you can decide what data gets transmitted to the third-party server; if you use just process the form as it goes by, you will be passing along all of the post data, which is not always what you want. Same for the 307 solution, assuming it worked for all of your users.

Hope this helps!

Answer 9

In PHP, you can send POST data with cURL. Is there something comparable for .NET?

Answer 10

In PHP, you can send POST data with cURL. Is there something comparable for .NET?

Yes, HttpWebRequest, see my post below.

Answer 11

The GET (and HEAD) method should never be used to do anything that has side-effects. A side-effect might be updating the state of a web application, or it might be charging your credit card. If an action has side-effects another method (POST) should be used instead.

So, a user (or their browser) shouldn't be held accountable for something done by a GET. If some harmful or expensive side-effect occurred as the result of a GET, that would be the fault of the web application, not the user. According to the spec, a user agent must not automatically follow a redirect unless it is a response to a GET or HEAD request.

Of course, a lot of GET requests do have some side-effects, even if it's just appending to a log file. The important thing is that the application, not the user, should be held responsible for those effects.

The relevant sections of the HTTP spec are 9.1.1 and 9.1.2, and 10.3.

Answer 12

Typically, all you'll ever need is to carry some state between these two requests. There's actually a really funky way to do this which doesn't rely on JavaScript (think <noscript/>).

Set-Cookie: name=value; Max-Age=120; Path=/redirect.html

With that cookie there, you can in the following request to /redirect.html retrieve the name=value info, you can store any kind of information in this name/value pair string, up to say 4K of data (typical cookie limit). Of course you should avoid this and store status codes and flag bits instead.

Upon receiving this request you in return respond with a delete request for that status code.

Set-Cookie: name=value; Max-Age=0; Path=/redirect.html

My HTTP is a bit rusty I've been going trough RFC2109 and RFC2965 to figure how reliable this really is, preferably I would want the cookie to round trip exactly once but that doesn't seem to be possible, also, third-party cookies might be a problem for you if you are relocating to another domain. This is still possible but not as painless as when you're doing stuff within your own domain.

The problem here is concurrency, if a power user is using multiple tabs and manages to interleave a couple of requests belonging to the same session (this is very unlikely, but not impossible) this may lead to inconsistencies in your application.

It's the <noscript/> way of doing HTTP round trips without meaningless URLs and JavaScript

I provide this code as a prof of concept: If this code is run in a context that you are not familiar with I think you can work out what part is what.

The idea is that you call Relocate with some state when you redirect, and the URL which you relocated calls GetState to get the data (if any).

const string StateCookieName = "state";

static int StateCookieID;

protected void Relocate(string url, object state)
{
    var key = "__" + StateCookieName + Interlocked
        .Add(ref StateCookieID, 1).ToInvariantString();

    var absoluteExpiration = DateTime.Now
        .Add(new TimeSpan(120 * TimeSpan.TicksPerSecond));

    Context.Cache.Insert(key, state, null, absoluteExpiration,
        Cache.NoSlidingExpiration);

    var path = Context.Response.ApplyAppPathModifier(url);

    Context.Response.Cookies
        .Add(new HttpCookie(StateCookieName, key)
        {
            Path = path,
            Expires = absoluteExpiration
        });

    Context.Response.Redirect(path, false);
}

protected TData GetState<TData>()
    where TData : class
{
    var cookie = Context.Request.Cookies[StateCookieName];
    if (cookie != null)
    {
        var key = cookie.Value;
        if (key.IsNonEmpty())
        {
            var obj = Context.Cache.Remove(key);

            Context.Response.Cookies
                .Add(new HttpCookie(StateCookieName)
                { 
                    Path = cookie.Path, 
                    Expires = new DateTime(1970, 1, 1) 
                });

            return obj as TData;
        }
    }
    return null;
}

Answer 13

It's pretty clear that the HTTP spec is mentally deficient.

HTTP and the Internet needs a complete redesign. That's also clear.

The point of this thread is basic and essential: How do we pass confidential, or at least non-exposed, parameters in an HTTP message.

It is clear that GET is a ridiculous, and insecure way, of passing parameters and leads to obvious, glaring security loopholes, and is completely wrong.

Message parameters in the HTTP header, should have been an XML structure to allow indefinite, expandable parameters to accommodate anything in the future. And now we're in the future, and stuck with this idiocy. Nice going.

As a result of this ongoing mental deficiency, developers struggle and waste their time with Javascript, cookies, session variables, doctored web pages, recursive server pages, and databases, none of which work reliably, universally, and securely across the board. All of this is simply working proof that REST is a hoax. And that maintaining state is essential, and must be implicitly and egalitarianly built into the architecture, which is just common sense.

A simple HTTP POST could solve many problems -- just set your header and go to the new url where you will see the variables in your POST array. And I'm not talking about getting a response back into your own url -- just go to the new url with the parameters in POST format. This is a common-sense message-passing protocol -- the first thing you would think of -- that HTTP does not support. And obviously, these parameters could be encrypted for confidentiality between sender and receiver.

And while we're at it, the entire master-slave, client-server model, is completely warped and wrong. A simple peer-to-peer message passing protocol is the way to go. That instead of the relationship being "hard-wired", it should be built upon building "sacred" globally-unique GUID messages, where everything is parameterized, including multicast, no need for response, and full or partial security between participants, where desired. And that reponse messages contain the unique message identifier that they are responding to -- correct communication -- and that the "DNS" is more active in managing and trafficing messages as dynamic URI's.

Well if you think it's time to change the internet, you are welcome to contact me. There is a comprehensive solution that I'll release in 2011 and would appreciate participants.

-- Infinitech.net

Answer 14

You can use this aproach:

Response.Clear();

StringBuilder sb = new StringBuilder();
sb.Append("<html>");
sb.AppendFormat(@"<body onload='document.forms[""form""].submit()'>");
sb.AppendFormat("<form name='form' action='{0}' method='post'>",postbackUrl);
sb.AppendFormat("<input type='hidden' name='id' value='{0}'>", id);
// Other params go here
sb.Append("</form>");
sb.Append("</body>");
sb.Append("</html>");

Response.Write(sb.ToString());

Response.End();

As result right after client will get all html from server the event onload take place that triggers form submit and post all data to defined postbackUrl.

Answer 15

Something new in ASP.Net 3.5 is this "PostBackUrl" property of ASP buttons. You can set it to the address of the page you want to post directly to, and when that button is clicked, instead of posting back to the same page like normal, it instead posts to the page you've indicated. Handy. Be sure UseSubmitBehavior is also set to TRUE.