You get a POST request that you want to redirect? Redirection has nothing to do with GET or POST, since it is a server response. I know of no way to tell the client "go there, but don't use GET, use POST". But you could do the post yourself on behalf of the client and deliver the response back to the client, thus acting as proxy. Why don't you set the action field of the form that is to be posted to the remote site in the first place?
From RFC2068, section 10.3.2:
If the 301 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after receiving
a 301 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
The same applies to 302 Moved Temporarily. It cannot be guaranteed that the client uses the same request method connecting the new location, if at all.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] |
I have to have it first post to my script, so I can apply their discounts to our software. If they have any or not, we do a few things, if they want a subscription then we give them a discount based on how much time they purchasing for our predictive dialer. If they don't then we don't create a subscription and I encrypt the paypal string using their system configuration and openssl.
For that to work, it has to be a POST, I have tried to just redirect them there with encrypt= and the whole string, but because there are multiple lines, it does not work. I guess that is the reason.
At any rate, I put a temporary solution on there, just letting them know, since they chose PayPal, and not a credit card, that they must first activate the software by clicking the activate button, which I just have post the form. I don't like it, since it seems redundant to me, nonetheless, it works, so I guess if Perl cannot POST to a url on a redirect, that will have to do.
Thank you, both, very much!
| [reply] |
It's not that Perl cannot POST a redirect ... no one can post a REDIRECT ... it's not part of the spec to begin with and more importantly, your looking at your HTTP verbs backwards ... GET, POST, PUT, DELETE are all things a client can ask of a server ... REDIRECTs are what servers ask of clients.
I don't think you've adequately outlined what you're trying to accomplish, so let me assume.
- You have a form that acts like a shopping cart
- users post to your form
- You do something with the form data
- You then pass the data onto ???
- ??? completes the transaction ???
it's steps 4 and 5 you're hazy on. Do they need to happen that way. Can you use LWP inside your script to post data to the other server and then parse the response? From that point of view, the transaction is transparent to the user (much in the same way CreditCard transactions are transparent - we as endusers, never see the payment gateway nor the merchant bank).
| [reply] |
There is no provision in HTTP for issuing a 3xx redirect that is not a GET request. Your only solution would be to use JavaScript or make the user push a button to submit the form.
| [reply] |
There is no provision in HTTP for issuing a 3xx redirect that is not a GET request.
This is not true. There are no provisions in HTTP for changing a GET request into another type of request, but if the original came in as a POST, you can send them to the new resource using a POST.
See section 10.3 of the HTTP/1.1 specs
Now, here're the problems -- some browsers treat a 302 as a 303. 301 (as mentioned in this thread), should NEVER be used under these sorts of circumstances, as it's cachable by proxies, and will tell the proxy or browser that it should NEVER come back to the original CGI. (some search engines will drop the item out of their index if they get a 301)
Now, in the case of a 302 on a POST, the browser is supposed to notify the user that they're being redirected to a new location. Most people don't like this, as it seems like a security problem.
As powerhouse has mentioned that this is specifically being sent to PayPal, I'm guessing that they've run into this issue before, and have solutions for dealing with it. As derby and Corion have suggested, the problem has nothing to do with Perl, as the issue is with HTTP, so more than likely PayPal has dealt with this many times over.
| [reply] |