why_does_the_address_bar_show.html 16.9 KB

Raw Blame History Permalink

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <style type="text/css" media="all">
    @import "/QA/2006/01/blogstyle.css";
    </style>
    <meta name="keywords" content='' />
    <meta name="description" content="An important feature of HTTP is the temporary redirect, where a resource can have a &quot;permanent&quot; 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..." />
    <meta name="revision" content="$Id: why_does_the_address_bar_show.html,v 1.26 2011/12/16 01:39:18 mirror Exp $" />
   <link rel="alternate" type="application/atom+xml" title="Atom" href="http://www.w3.org/QA/atom.xml" />
   <link rel="alternate" type="application/rss+xml" title="RSS 1.0" href="http://www.w3.org/QA/news.rss" />
   <title>Why does the address bar show the tempolink instead of the permalink? - W3C Blog</title>

   <link rel="start" href="http://www.w3.org/QA/" title="Home" />
   <link rel="prev" href="http://www.w3.org/QA/2010/03/html_5_meetup_-_paris.html" title="HTML5 Meetup - Paris" />
   <link rel="next" href="http://www.w3.org/QA/2010/04/volcanic_ash_europe_and_w3c.html" title="Volcanic ash, Europe, and W3C" />

   <!--
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
         xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description
    rdf:about="http://www.w3.org/QA/2010/04/why_does_the_address_bar_show.html"
    trackback:ping="http://www.w3.org/QA/sununga/mt-tb.cgi/316"
    dc:title="Why does the address bar show the tempolink instead of the permalink?"
    dc:identifier="http://www.w3.org/QA/2010/04/why_does_the_address_bar_show.html"
    dc:subject="Web Architecture"
    dc:description="An important feature of HTTP is the temporary redirect, where a resource can have a &quot;permanent&quot; 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..."
    dc:creator="Jonathan Rees"
    dc:date="2010-04-19T13:59:40+00:00" />
</rdf:RDF>
-->

    <!-- <script type="text/javascript" src="http://www.w3.org/QA/mt.js"></script>-->

</head>
<body class="layout-one-column">
      <div id="banner">
      <h1 id="title">
	<a href="http://www.w3.org/"><img height="48" alt="W3C" id="logo" src="http://www.w3.org/Icons/WWW/w3c_home_nb" /></a>
W3C Blog
</h1>
    </div>

    <ul class="navbar" id="menu">
        <li><strong><a href="/QA/" title="W3C Blog Home">[ W3C Blog ]</a></strong></li>
        <li><a href="/QA/Library/" title="Documents and Publications on Web and Quality">Documents</a></li>
        <li><a href="/QA/Tools/" accesskey="3" title="Validators and other Tools">Tools</a></li>
        <li><a href="/2007/12/qa-blog-help/index#feedback">Feedback</a></li>
    </ul>
<div id="searchbox">
<form method="get" action="http://www.google.com/custom" enctype="application/x-www-form-urlencoded">
<p id="formbox"><input type="text" size="15" class="textfield" name="q" accesskey="E" maxlength="255" /> <input type="submit" class="submitfield" value="Search" id="goButton" name="sa" accesskey="G" /> <input type="hidden" name="cof" value="T:black;LW:72;ALC:#ff3300;L:http://www.w3.org/Icons/w3c_home;LC:#000099;LH:48;BGC:white;AH:left;VLC:#660066;GL:0;AWFID:0b9847e42caf283e;" /><input type="hidden" id="searchW3C" name="sitesearch" checked="checked" value="www.w3.org/QA" /><input type="hidden" name="domains" value="www.w3.org/QA" /></p>
</form>
</div>


    <div id="main"><!-- This DIV encapsulates everything in this page - necessary for the positioning -->

                     <p class="content-nav">
                        <a href="http://www.w3.org/QA/2010/03/html_5_meetup_-_paris.html">&laquo; HTML5 Meetup - Paris</a> |
                        <a href="http://www.w3.org/QA/">Main</a>
                        | <a href="http://www.w3.org/QA/2010/04/volcanic_ash_europe_and_w3c.html">Volcanic ash, Europe, and W3C &raquo;</a>
                     </p>

                        <h2 class="entry-header">Why does the address bar show the tempolink instead of the permalink?</h2>
                           <div class="entry-body">
                              <p>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.</p>

<p>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 <a href="http://www.w3.org/DesignIssues/UserAgent">User Agent watch points</a>
(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 <a href="http://www.w3.org/TR/2003/NOTE-cuap-20030128">Common User
Agent Problems</a>: "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."</p>

<p>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:</p>

<ol>
<li><p>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</p></li>
<li><p>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</p></li>
<li><p>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</p></li>
<li><p>user enters their W3C password into phishing form, etc.</p></li>
</ol>

<p>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.</p>

<p>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 .</p>

<p>This line of reasoning is documented in the Wikipedia article <a href="http://en.wikipedia.org/wiki/URL_redirection#Manipulating_visitors">URL redirection</a> and its references and
in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=68423">Mozilla bug 68423</a>.</p>

<p>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.</p>

<p>If browser projects are unwilling to change address bar behavior - and
it seems unlikely that they will - is there any other remedy?</p>

<p>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.</p>

<p>(Thanks to Dan Connolly, other TAG members, and David Wood for their
help with this note.)</p>

                           </div>
                           <div id="more" class="entry-more">


                           </div>
                       <p class="postinfo">Filed by <a href="">Jonathan Rees</a> on April 19, 2010  1:59 PM in <a href="http://www.w3.org/QA/archive/web_architecture/">Web Architecture</a><br />
<span class="separator">|</span> <a class="permalink" href="http://www.w3.org/QA/2010/04/why_does_the_address_bar_show.html">Permalink</a>
                                 | <a href="http://www.w3.org/QA/2010/04/why_does_the_address_bar_show.html#comments">Comments (4)</a>
                                 | <a href="http://www.w3.org/QA/2010/04/why_does_the_address_bar_show.html#trackback">TrackBacks (0)</a>
</p>


<h3 class="comments-header" id="comments">Comments</h3>
<div class="comment" id="comment-190143">
<p class="comment-meta" id="c190143">
<span class="comment-meta-author"><strong>Peter Mumford </strong></span>
<span class="comment-meta-date"><a href="#c190143">#</a> 2010-04-19</span>
</p>
<div class="comment-bulk">
<p>A solution exists already. Back in 2008, Tamura Jones (of JavaScript-free Chrome Frame detection fame) wrote the permalink trilogy, which discusses permalink conventions and best practice, and suggested that bookmarkers recognize class="permalink" to make sure they bookmark the permalink to a page instead of a tempolink: <a href="http://www.tamurajones.net/MarkingPermalinks.xhtml" rel="nofollow">Marking Permalinks</a>.</p>

</div>
</div>


<div class="comment" id="comment-190144">
<p class="comment-meta" id="c190144">
<span class="comment-meta-author"><strong>basa </strong></span>
<span class="comment-meta-date"><a href="#c190144">#</a> 2010-04-19</span>
</p>
<div class="comment-bulk">
<p>I actually <em>want</em> 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.</p>

</div>
</div>


<div class="comment" id="comment-190156">
<p class="comment-meta" id="c190156">
<span class="comment-meta-author"><strong>dave singer </strong></span>
<span class="comment-meta-date"><a href="#c190156">#</a> 2010-04-19</span>
</p>
<div class="comment-bulk">
<p>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.  </p>

<p>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.</p>

</div>
</div>


<div class="comment" id="comment-190548">
<p class="comment-meta" id="c190548">
<span class="comment-meta-author"><strong>David Wood </strong></span>
<span class="comment-meta-date"><a href="#c190548">#</a> 2010-04-26</span>
</p>
<div class="comment-bulk">
<p>Dave Singer has got it in one.  Browser behavior isn't really the issue here; browser user interface real estate is the issue.</p>

<p>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.</p>

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

</div>
</div>


  <div class="comments-open" id="comments-open">
<h3 class="comments-open-header">Leave a comment</h3>

<div class="comments-open-moderated">
   <p>
   Note: this blog is intended to foster <strong>polite
   on-topic discussions</strong>. Comments failing these
   requirements and spam will not get published. Please,
   enter your real name and email address. Every
   individual comment is reviewed by the W3C staff.
   This may take some time, thank you for your patience.
   </p>
   <p>
   You can use the following HTML markup (a href, b, i,
   br/, p, strong, em, ul, ol, li, blockquote, pre)
   and/or <a href="http://daringfireball.net/projects/markdown/syntax">Markdown syntax</a>.</p>
</div>

<div id="comments-open-data">
<form method="post" action="http://www.w3.org/QA/sununga/beach.pl" id="comments-form">
<h4>Your comment</h4>
<div id="comments-open-text">
  <textarea id="comment-text" name="text" rows="20" cols="100"></textarea><br />
<label for="comment-text">Write your comment text here. Remember, keep the discussion on topic and courteous.</label>
</div>

<h4>About you</h4>
<div id="comment-form-name">
  <input type="hidden" name="static" value="1" />
<input type="hidden" name="entry_id" value="8769" />
<input type="hidden" name="__lang" value="en" />
<label for="comment-author">Your Name</label>
<input id="comment-author" name="author" size="30" value="" />
</div>
<div id="comment-form-email">
<label for="comment-email">Your Email Address</label>
<input id="comment-email" name="email" size="30" value="" />
</div>

<div id="comments-open-footer">
<input type="submit" accesskey="s" name="post" id="comment-submit" value="Submit" />

</div>
</form>
</div>
</div>


<p id="gentime">This page was last generated on $Date: 2011/12/16 01:39:18 $</p>

      </div><!-- End of "main" DIV. -->

<address>

This blog is written by W3C staff and working group participants,<br />
&nbsp;and maintained by <a href="/People/CMercier/">Coralie Mercier</a>.<br />
Authorized parties may <a href="/QA/new">log in</a> to create a new entry.<br/>
<span id="poweredby">Powered by Movable Type, magpierss and a lot of Web Technology</span>
    </address>


    <p class="copyright">
      <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &copy; 1994-2011
      <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a>&reg;
      (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>,
      <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
      <a href="http://www.keio.ac.jp/">Keio</a>),
      All Rights Reserved.
      W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
      <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
      <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
      and <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a>
      rules apply. Your interactions with this site are in accordance
      with our <a href="http://www.w3.org/Consortium/Legal/privacy-statement#Public">public</a> and
      <a href="http://www.w3.org/Consortium/Legal/privacy-statement#Members">Member</a> privacy
      statements.
    </p>

  </body>
</html>