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” [302] 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:

1. 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

2. 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

3. 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

4. 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.)