tags:

views:

215

answers:

2

I want the browser to reflect some other URL than the one used to create the request, but without roundtripping to the server.

I would maybe do this:

POST /form HTTP/1.1
...

...and then return:

HTTP/1.1 200 OK
Location: /hello

But that would cause a redirect, the browser will again, request URL /hello.

I would like to just tell the browser that, while the request you just sent was POST /some_url the actuall resource that I'm now returning is actually called GET /hello/1 but without preforming a roundtrip. i.e. Location: ...

Is there any way to do this with JavaScript or the base="" attribute? That will tell the browser to request /hello/1 when I hit F5 (refresh) instead of that, post submission warning?

+5  A: 
HTTP/1.1 200 OK
Location: /hello

Actually that probably wouldn't work; it should be a 30x status rather than 200 (“303 See Other” is best for the response to a POST), and ‘Location’ should be a complete absolute URL.

(If your script just says ‘Location: /relativeurl’ without the 30x status, CGI servers will usually do an internal redirect by fetching the new URL and returning it without telling the browser anything funny happened. This may sound like what you want but it isn't really because from the browser's point of view it's no different from the original script returning a 200 and direct page.)

But that would cause a redirect, the browser will again, request URL /hello.

In practice that's probably not as bad as you think, thanks to HTTP/1.1 keep-alives. The client should be able to respond to the redirect straight away (in the next packet) as long as it's on the same server.

Is there any way [...] That will tell the browser to request /hello/1 when I hit F5 (refresh) instead of that, post submission warning?

Nope. Stick with the POST-Redirect-GET model for solving this.

bobince
OK, here's the thing, there's a reason why I don't want the roundtrip and it's not the preformance. It's preferable if I can prepare the response in combination with the request, I might wanna pass and/or manipulate that request depending on the POST and it can't be done as easily if I roundtrip.
John Leidegren
I tried using an unique ID and roundtripping that by putting it in a cookie with the path set to /hello/1. That value would then be picked up by the GET /hello/1 and server-side, I would be able to pickup whatever state I was caching for that request. This works, but what do think?
John Leidegren
What I usually do is put a parameter on the redirect query string for the subsequent request to pick up. Because cookies are shared between all pages/windows open on the site, the parameter makes sure that the post-action response information goes to the right window.
bobince
(And then I back this up with a timestamp value, so the post-action information ‘expires’ after a little while. So that if you bookmark or otherwise go back to the same URL, the same information doesn't appear again.)
bobince
If you have a *lot* of data to output in response to an action this may not be so practical, however; you'd could store it temporarily in the database and key it in a parameter, but that's starting to get a bit annoying to implement.
bobince
A: 

No. Http is stateless, and every request has one answer. When you post, you need to redirect to a get page immediately to prevent a double post - you don't want it to sit on that post url. The redirect is what tells the browser that it is on a new page. That's just the way it works.

DGM