Hi Jeff As I understand it, the reason for this is that browsers (incorrectly) treat the 302 redirect as a GET regardless of the initial request http://en.wikipedia.org/wiki/HTTP_302 My approach to this would be to store the parameters in the user's session. Then create an 'any' checkout handler. Therefore, regardless of whether you wind up with a GET or POST, you can get the data from your own server rather than from the client's browser. Andrew On Thu, Jan 8, 2015 at 7:48 PM, Jeff Boes <jeff@endpoint.com> wrote:
I have a page that responds to a POST request:
post '/checkout' => sub { ... };
Then, I have another page that does some different work before this page can be processed. I want to redirect to the /checkout page as a POST, so the URL ends up as "/checkout" with no visible parameters.
Long version of the explanation: the /checkout page is my cart checkout page. However, the user might be an "admin" user, working from an order creation page that is unlike the normal cart page. So while a normal user goes through
/flypage => /cart => /checkout
an Admin user would go through
get /order/new => post /order/new => /checkout
I got this working with a "forward" operation at the end of my interstitial page,
forward '/checkout', { ... several parameters here ... };
but the only drawback here is that the admin user ends up looking at a URL that is not "/checkout", even though the page contents are what they would see at "/checkout".
I can get the URL right if I replace "forward" with "redirect":
redirect uri_for '/checkout', { ... several parameters here ... }
which leaves the browser at
.../checkout?foo=...&bar=...&blah=...
Ugly. I just want to end up on "/checkout", with my parameters hidden away. Is there any hope?
-- Jeff Boes <>< jeff@endpoint.com 269-408-0811 _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- Andrew Solomon Mentor@Geekuni http://geekuni.com/ http://www.linkedin.com/in/asolomon