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://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.
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.)