An important feature of HTTP is the temporary redirect, where a resource can have a “permanent” URI while its content moves from place to place over time. For example, http://purl.org/syndication/history/1.0 remains a constant name for that resource even though its location (as specified by a second URI) changes from time to time.
If this is such a useful feature, then why does the browser address bar show the temporary URI instead of the permanent one? After all, the permanent one is the one you want to copy and paste to email, to bookmark, to place in HTML documents, and so on. The HTTP specification says to hang on to the permanent link (“since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests.”). Tim Berners-Lee says the same thing in User Agent watch points (1998): “It is important that when a user agent follows a “Found”  link that the user does not refer to the second (less persistent) URI. Whether copying down the URI from a window at the top of a document, or making a link to the document, or bookmarking it, the reference should (except in very special cases) be to the original URI.” Karl Dubost amplifies this in his 2001-2003 W3C Note Common User Agent Problems: “Do not treat HTTP temporary redirects as permanent redirects…. Wrong: User agents usually show the user (in the user interface) the URI that is the result of a temporary (302 or 307) redirect, as they would do for a permanent (301) redirect.”
So why do browsers ignore the RFC and these repeated admonitions? Possibly due to lack of awareness of the issue, but more likely because the status quo is seen as protecting the user. If the original URI (the permalink) were shown we might have the following scenario:
an attacker discovers a way to establish a 3xx redirect from http://w3.org/resources/looksgood to http://phishingsite.org/pretendtobew3 – either because w3.org is being careless, or because of a conscious decision to deed part of its URI space to other parties
user sees address bar = http://w3.org/resources/looksgood with content X, and concludes that the X is attributable to the resource http://w3.org/resources/looksgood
user treats the http://w3.org/ prefix as an informal credential and treats the http://w3.org/resources/looksgood content as coming from W3C (without any normative justification; they just do) when in fact it’s a phishing site pretending to be W3C
user enters their W3C password into phishing form, etc.
Were the user to observe address bar = http://phishingsite.org/pretendtobew3 with the same content, she might suspect an attack and decline to enter a password.
An attacker might make use of an explicit redirection service on a site similar to that provided by purl.org, or it might exploit a redirect script that takes a URL as part of the query string, e.g. http://w3.org/redirect?uri=http://phishingsite.org/pretendtobew3 .
This line of reasoning is documented in the Wikipedia article URL redirection and its references and in Mozilla bug 68423.
There are two possible objections. One is that the server in these cases is in error – it shouldn’t have allowed the redirects if it didn’t really mean for the content source to speak on behalf of the original resource (similar to an iframe or img element). The other is that the user is in error – s/he shouldn’t be making authorization decisions based on the displayed URI; other evidence such as a certificate should be demanded. Unfortunately, while correct in theory, neither of these considerations is very compelling.
If browser projects are unwilling to change address bar behavior – and it seems unlikely that they will – is there any other remedy?
Perhaps some creative UI design might help. Displaying the permalink in addition to the tempolink might be nice, so that it could be selected (somehow) for bookmarking, but that might be confusing and take too much screen real estate. One possible partial solution would be an enhancement to the bookmark creation dialog. In Firefox on selecting “Bookmark This Page” one sees a little panel with text fields “name” and “tags” and pull-down “folder”. What if, in the case of a redirection, there were an additional control that gave the option of bookmarking the permalink URI in place of the substitute URI? With further thought I bet someone could devise a solution that would work for URI copy/paste as well.
(Thanks to Dan Connolly, other TAG members, and David Wood for their help with this note.)
4 thoughts on “Why does the address bar show the tempolink instead of the permalink?”
I actually want to know where I am being redirected. There are just too much clunky web site configurations out there. For us to assume that everything is in good order is very optimistic. Furthermore, when the site wishes to provide stuff that has to point to a different version over time, a cleaner method is to use Apache rewrites, (for non-techies:) which “forwards” the request internally, on the server itself, and returns the result of the proper version.
The problem is that the address bar is serving two functions (at least): “what am I actually reading?” and “what is the reference to what I am reading?”. Showing the redirect answers (a) but not (b), and the reverse is true if you don’t.
Perhaps we need a better way to get a reference; after all, you have to ‘just know’ if there is an anchor on the page you could point to, that would serve as a more precise reference. Some visual indication or affordance that showed where the closest anchor is (if any) and allowed you to copy the permalink (maybe #anchor) to the clipboard for pasting.
Dave Singer has got it in one. Browser behavior isn’t really the issue here; browser user interface real estate is the issue.
I think we want users to know when they have been redirected, or at least to be able to get that information. We also want them to have the (recommended) option of bookmarking the permalink.
Tamura Jones’ solution requires HTML authors to anticipate user behavior, which is not a complete solution, IMO. I think a better option is for browser vendors to denote a redirection visually in the address bar while showing the permalink. Selecting the visual indication of a redirection could show the tempolink. That solution would be similar in concept to the display of a “lock” icon for SSL/TLS connections (including the display of certificate information in some browers when the lock icon is selected).
Comments are closed.