W3C home > Mailing lists > Public > public-html-comments@w3.org > September 2009

redirect handling specification

From: Arthur Clifford <art@artspad.net>
Date: Tue, 1 Sep 2009 21:07:49 -0700
To: <public-html-comments@w3.org>
Message-ID: <005b01ca2b82$efd7f190$0e14a8c0@iMacPCVirtualMachine>


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:03:58 UTC