(Draft of possible TAG blog post) A[n information] resource is a virtual entity to which information may be attributed. When we do an HTTP GET to get some information from a server, and the server sends a 200 response, the server is saying that the payload of the response is attributable to the resource - the resource "says" the payload. So what does a 3xx redirect response tell us? RFC 2616 says the following for 307 Temporary Redirect: "The requested resource resides temporarily under a different URI." That is, for as long as the 307 is valid (cacheable), a request on the second (temporary, "different") URI can be used to satisfy a request on the original URI. Now the second URI itself identifies some resource. If the temporary URI's server tells us that the second resource says something (200), then, if we believe what the 307 response says, the original resource says it, too. 2616 goes on to say "Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests." This sounds useful and correct, but most user-agents ignore this advice by displaying the second URI in the browser address bar, using it in preference to the original for bookmarking, and so on. Karl Dubost in the 2001-2003 W3C Note "Common User Agent Problems" http://www.w3.org/TR/2003/NOTE-cuap-20030128 urged browser implementors to change their ways: "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." This advice reiterates Tim Berners-Lee's long-standing instruction http://www.w3.org/DesignIssues/UserAgent (1998): "It is important that when a user agent follows a "Found" [302] link that the user does not refer to the second (less persistenet) 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." Giovanni Tummarello repeated the complaint in 2007: http://lists.w3.org/Archives/Public/www-tag/2007Jul/0034.html "This is highly confusing and can lead to errors.. e.g. copy pasting it from the browser to send it for reference in a email or IM or to a semantic web client would result in the wrong URI be[ing] used..." He was speaking specifically of 303 redirects (in fact he took this as a reason not to use 303s at all as suggested by the httpRange-14 resolution http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html), but the same problem applies equally to 307 and to 302. So why do browsers ignore the RFC and this repeated advice? Possibly due to lack of awareness, but more likely because the status quo is seen as protection in cases where there is a 3xx response but the second resource does *not* speak for the first resource. This would happen in the following scenario: 1. domain owner A gives attacker B the ability to establish a 3xx redirect from URI U to URI V - either through carelessness or by a conscious decision to deed part of its URI space to other parties 2. user C sees address bar = U with content X, and concludes (correctly) that resource U says X 3. user C treats resource U as speaking for A (without any normative justification, but naturally, because of trust in the domain name component of U) Were user C to observe address bar = V with content X, X would not be attributed to the resource named U, and all would be well. Of course, if the attacker controlled 200 responses at U (e.g. through upload or PUT), there would be no such protection against phishing attacks. This line of reasoning is documented in the Wikipedia article "URL redirection" http://en.wikipedia.org/wiki/URL_redirection and in Mozilla bug 68423 https://bugzilla.mozilla.org/show_bug.cgi?id=68423 . The overwhelming difficulty in bookmarking a redirected URI - because the URI in the address bar is not the one that's supposed to be bookmarked - is an ongoing problem that plagues semantic web applications (which use 303 liberally), redirection services such as OCLC's purl.org, and probably many other applications. If the browser providers are unwilling to change the address behavior - and this seems unlikely - is there any other remedy? Putting the whole redirection chain in the browser window might be nice, so that any could be selected (somehow) for bookmarking, but that would obviously take too much real estate. One possibility 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 "bookmark original URI" in this panel that gave the option of bookmarking the original URI in place of the substitute URI? Well, some user interface designer would have to make it completely clear what's going on, but you get the idea.