redirect handling specification



As a non-W3C member, I'm not sure what the proper procedure is for
recommending changes to specifications. I apologize in advance if this is
not the appropriate mailing list for this message .


I was noticing recently that when I read blogs/articles that discuss
http-redirects that they include the caveat that re-directs may cause
browser navigation (back button) to mess up; in turn causing
user-dissatisfaction. I think that problem should really be addressed.
http-redirects, especially from a server after having performed some
authentication or other checks can be quite useful.


The answer seems relatively simple; a browser handling an http-redirect
should replace the calling page in the browser history with the page being
redirected to. So, user navigates from page A to page B, page B redirects to
page C. User hits the back button and gets page A.


There may be legitimate reasons why current behavior of a redirect would be
desirable. If so, then would it be better to have a navigate-to header
option that tells the browser to go to a new page rather than replace the
current one in the history?


Of course for backward-compatability current behavior could be left alone
and a replace-page header or something to that effect could be implemented
that would tell the browser/client how to treat a redirect intended to
replace a page rather than navigate away from it.


Perhaps this is more of an http than an html issue, if there is a better
list to submit this to please let me know.


-Art C 


Arthur Clifford

Received on Wednesday, 2 September 2009 14:11:48 UTC