Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

HTTP redirects are done via HTTP codes 301, and 302 (maybe other codes also) and a header field known as "Location" which has the address of the new place to go. However, browsers always send a "GET" request to that URL.

However, many times you need to redirect your user to another domain via POST (bank payments for example). This is a common scenario, and really a requirement. Does anybody know why such a common requirement has been neglected in HTTP specification? The workaround is to send a form (with parameters in hidden fields) with action set to the target location (the value of the Location header field) and use setTimeout to submit the form to the target location.

share|improve this question
    
Is status code 307 what you're looking for? See my answer below. –  David Ruttka Aug 10 '11 at 13:51

3 Answers 3

up vote 30 down vote accepted

In HTTP 1.1, there actually is a status code (307) which indicates that the request should be repeated using the same method and post data.

As others have said, there is a potential for misuse here which may be why many frameworks stick to 301 and 302 in their abstractions. However, with proper understanding and responsible usage, you should be able to accomplish what you're looking for.

Note that according to the W3.org spec, when the METHOD is not HEAD or GET, user agents should prompt the user before re-executing the request at the new location. You should also provide a note and a fallback mechanism for the user in case old user agents aren't sure what to do with a 307.

Using this form:

<form action="Test307.aspx" method="post">
    <input type="hidden" name="test" value="the test" />
    <input type="submit" value="test" />    
</form>

And having Test307.aspx simply return 307 with the Location:http://google.com, Chrome 13 and Fiddler confirm that "test=the test" is indeed posted to Google. Of course the further response is a 405 since Google doesn't allow the POST, but it shows the mechanics.

For more information see List of HTTP status codes and the W3.org spec.

307 Temporary Redirect (since HTTP/1.1) In this occasion, the request should be repeated with another URI, but future requests can still use the original URI.2 In contrast to 303, the request method should not be changed when reissuing the original request. For instance, a POST request must be repeated using another POST request.

share|improve this answer
    
Many thanks @druttka. +1. :) –  Saeed Neamati Aug 10 '11 at 18:42
    
@Saeed No problem. If this solved your issue and you wouldn't mind marking it as accepted, it might help people find it in the future. –  David Ruttka Aug 10 '11 at 19:25
    
@DavidRuttka, What's the browser support in the wild? –  Pacerier May 12 at 9:32

I found a good explanation on this page here.

The simplest situations on the WWW are "idempotent" transactions, i.e those which can be repeated without causing any harm. These are typically "GET" transactions, either because they are retrieval of straightforward URL references (e.g href= or src= attributes in HTML), or because they are form submissions using the GET method. Redirecting a transaction of that kind is straightforward, and no questions asked: the client receives the redirection response, including a Location: header that specifies the new URL, and the client reacts to it by re-issuing the transaction to the new URL. There's a difference between the different 30x status codes associated with these redirections in their implied cacheability, but otherwise they are basically similar (301 and 302) in response to GET requests.

POST transactions are different, since they are defined to be, in principle, non-idempotent (such as ordering a pizza, casting a vote or whatever) and mustn't be arbitrarily repeated.

The HTTP protocol specifications are designed to take this distinction into account: the GET method is defined to be inherently idempotent, whereas the POST method is defined to be, at least potentially, non-idempotent; the specifications call for a number of precautions to be taken by client agents (such as browsers) for protecting users against inadvertently (re)submitting a POST transaction which they had not intended, or submitting a POST into a context which they would not have wanted.

While I am not a fan of restricing users technically to prevent them from causing unwanted mayhem or doing unwanted harm to their applications, I can understand the point and it makes sense.

share|improve this answer
    
much of the reasoning goes to the days when the intertubes were slow and unreliable (which they still are in many locations of the world). I distinctly remember when I used dial up and would randomly be disconnected whenever someone else picked up the phone. It was better to reload the page and see what state the server was in than to resubmit things and run the risk of performing the same action twice. –  zzzzBov Aug 10 '11 at 13:55
    
@Falcon, Would increasing the "visitor counter" be considered non-idempotent? If so, almost no websites these days do idempotent GETs... –  Pacerier May 12 at 9:35

Another possible reason that I can think of would be in the case of a redirect to another web server.

You would not want to allow a redirecting server to set variables via POST on a remote server arbitrarily. The potential for abuse here would be enormous, I would think.

share|improve this answer
    
-1, This answer plays into the false premise of the question and employs speculation rather than any canonical information. –  tuespetre Jul 14 at 14:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.