Yes, using 307 response code and HTTP 1.1 compliant browser.Originally Posted by atsch
http://ppewww.ph.gla.ac.uk/%7Eflavel...-redirect.html
Yes, using 307 response code and HTTP 1.1 compliant browser.Originally Posted by atsch
http://ppewww.ph.gla.ac.uk/%7Eflavel...-redirect.html
cool.
Didn't know that![]()
Is there a way we can use this with a redirect view?Originally Posted by rector
A web framework "Stripes" claimed that it support "Redirect-after-Post"*.
Will spring support this feature in the near future ?
moon
*http://stripes.mc4j.org/confluence/d...ate+Management
Spring already "supports" this.Originally Posted by yfmoan
It is basically stating that after doing receiving a POST the server should not forward to a view, rather it should send a view that is a redirect to the view.
In plain English, if I have a view which allows users to enter details mapped to "/users/create.htm" and a success view mapped to "/users/created.htm" then the sequence of events should be:
- browser requests /users/create.htm
- user fills in details and submits a POST
- server creates the user and *sends a redirect* to /users/created.htm
It is the last point that is key. You can already do this in Spring![]()
Hi yatesco ,
you mean we can do "Redirect-after-Post" with those "POST parameters" included in spring now ? ai ....when they added the feature ?
what l mean is (from the link l given above) ,
moon.Redirect-after-Post is the name given to a fairly simple technique. The idea is that after a form POST has occurred and the server has done something significant (create a user, place a trade etc.) that it is safest to then redirect the user to another (or perhaps the same) page. By redirecting we ensure that if the user hits the refresh button they don't re-submit the form. If we were to have simply forwarded to a page after the POST, a refresh would re-post the form!
But there is a down side to redirecting. Anything stored in request attributes is lost when the redirect is issued (because the request for the page is not the same request). One option is to stuff things into session, but that's a bad idea(tm) because it things will break when the user has more than one browser window open using your application.
Anything in the ModelAndView will be appended to the redirect URL.
In the user use case above, it is likely that the /users/created.htm requires the userId, so the ModelAndView used to issue the redirect should include it.
Oh ....there is a misunderstanding here , may be is my bad .
yes , spring can support that .
but what l want is the POST parameters NOT SHOW in the url after a redirect , that mean redirect AGAIN using POST method to send the previous POST parameter ..
sorry for being unclear.
moon
Oh I see.
Not sure then.
(you were clear; I was just loosing track of the thread)
Last edited by Colin Yates; Apr 13th, 2006 at 08:43 AM.