Re: [CODE4LIB] Temporary redirection and the location bar

[Erik Hetzner]

At Fri, 26 Feb 2010 10:00:15 -0500,
Esme Cowles escow...@ucsd.edu wrote:

 One solution to this problem is to use a reverse proxy instead of a
 redirect. We do this for our ARKs, so temporary URL is not shown to
 the end user at all.

 This is not a general solution, especially for people who are
 redirecting externally and are concerned about the phishing scenario
 described in:

 http://www.w3.org/TR/2001/NOTE-cuap-20010206#cp-temp-redir

 I think the ideal solution would be to have the browser location bar
 show the original URL, with a conspicuous indication of redirection,
 which would provide access to the redirection chain and the final
 URL. Bookmarking would default to the original URL, but provide the
 option of using the final URL instead.

Hi Esme -

This is a great solution, as long as you control both sides. Thanks
for pointing it out.

Your solution for the browser is very close to one proposed at [1].
This bug is now 9 years old.

I believe that there is some reluctance among browser authors to
change the behavior at this point.

If others on this list are interested in persistent identifiers, and
you have some time, I think it would be worth your while to research
this issue. It might be useful in the future to demonstrate that there
are people who care about this issue.

best,
Erik Hetzner

1. https://bugzilla.mozilla.org/show_bug.cgi?id=68423#c11
;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3


pgpUfnYxI1wpL.pgp
Description: PGP signature

[CODE4LIB] Temporary redirection and the location bar

[Erik Hetzner]

Hi -

This is an issue which is of great importance to persistent
identifiers on the web, and one which I thought should be brought to
the attention of the c4l community. It affects PURLs, ARKs, and in
general any system that redirects a persistent or permanent URI to
another, temporary URI. I did not, however, realize that there was
active debate about it.

Briefly, from [1]:

  3.4 Do not treat HTTP temporary redirects as permanent redirects.

  The HTTP/1.1 specification [RFC2616] specifies several types of
  redirects. The two most common are designated by the codes 301
  (permanent) and 302 or 307 (temporary):

  * A 301 redirect means that the resource has been moved permanently
and the original requested URI is out-of-date.

  * A 302 or 307 redirect, on the other hand, means that the resource
has a temporary URI, and the original URI is still expected to
work in the future. The user should be able to bookmark, copy, or
link to the original (persistent) URI or the result of a temporary
redirect.

  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.

There is more info at [2]. You can find the email thread at [3].

best,
Erik Hetzner

1. http://www.w3.org/TR/2001/NOTE-cuap-20010206#cp-temp-redir
2. http://www.w3.org/2001/tag/group/track/issues/57
3. 
http://www.w3.org/mid/760bcb2a1002231400m5e9b2bb6rc80bb43c37a81...@mail.gmail.com

---BeginMessage---
http://www.w3.org/2001/tag/2010/02/redirects-and-address-bar.txt

Written in the style of a blog post, and making use of
state-of-the-art theory (such as it is) of http semantics.

If this gets review and approval of some kind (especially from TimBL,
who has been the vocal campaigner on this question) I'll htmlify and
post it and be done with this action. Not sure what else to do.

Jonathan

---End Message---


pgpMRUclrgHer.pgp
Description: PGP signature