68423 - W3C CUAP: Do not treat HTTP temporary redirects as permanent redirects

Status: NEW

(SeaMonkey :: Location Bar, defect)

Description

[Gervase Markham [:gerv]]

[ This bug is one of the recommendations in the W3C's "Common User Agent 
Problems" document, URL above. One bug has been filed on each recommendation, 
for deciding whether we do it and, if not, whether we should. ]

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

        o A 301 redirect means that the resource has been moved permanently
          and the original requested URI is out-of-date.
        o 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.

Comment 1

[Andreas M. "Clarence" Schneider]

This recommendation may be appropriate for 307, but it is not for 302.
302 commonly is used when 303 was meant (HTTP/1.0 did not have such a status).

Adding dependency on bug 48202 "HTTP responses 303 and 307 not handled".
A testcase is at http://clarence.de/post-test/form.html .

Comment 2

[Karl Ove Hufthammer]

The RFC (2616) says:

10.3.3  302 Found

   The requested resource resides temporarily under a different URI.
   Since the redirection might be altered on occasion, the client SHOULD
   continue to use the Request-URI for future requests.  This response
   is only cacheable if indicated by a Cache-Control or Expires header
   field.

   The temporary URI SHOULD be given by the Location field in the
   response. Unless the request method was HEAD, the entity of the
   response SHOULD contain a short hypertext note with a hyperlink to
   the new URI(s).

   If the 302 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client.



10.3.8  307 Temporary Redirect

   The requested resource resides temporarily under a different URI.
   Since the redirection MAY be altered on occasion, the client SHOULD
   continue to use the Request-URI for future requests.  This response
   is only cacheable if indicated by a Cache-Control or Expires header
   field.

   The temporary URI SHOULD be given by the Location field in the
   response. Unless the request method was HEAD, the entity of the
   response SHOULD contain a short hypertext note with a hyperlink to
   the new URI(s) , since many pre-HTTP/1.1 user agents do not
   understand the 307 status. Therefore, the note SHOULD contain the
   information necessary for a user to repeat the original request on
   the new URI.

   If the 307 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

Comment 3

[Matthew Tuck [:CodeMachine]]

Bug #8648 is related to this.

Comment 4

[benc]

mass move, v2.
qa to me.

Comment 5

[Tom Mraz]

Updating dependency on the duplicate.

Comment 6

[Doug Turner (:dougt)]

moving neeti's futured bugs for triaging.

Comment 7

[benc]

-> HTTP

Comment 8

[Darin Fisher]

WORKSFORME.  been fixed for a while now.

Comment 9

[Aaron Swartz]

Umm, are you sure? I just downloaded the latest nightly[1] and tried to visit my
test page[2] and I got the page I was redirected to[3] in the URL bar.

[1] Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021003
[2] http://www.aaronsw.com/2002/redirecttest/
[3] http://www.mozilla.org/

What browser are you using where visiting
http://www.aaronsw.com/2002/redirecttest/ gives you that URL in the URL bar? On
everything I've tried I get http://www.mozilla.org/

Please reopen this bug until it actually works.

Comment 10

[Tom Everingham]

ok I'm confused, the test site supplied in comment# 9 returns a 307 Temporary
Redirect in response to a GET and the browser redirects to the mozilla site and
the location bar is updated.

But the w3c problems document says -

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

And rfc 2616 says

"If the 307 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user"

which implies you should get redirected if a GET was originally sent.

Don't these contradict each other?

Comment 11

[Aaron Swartz]

No. Here's what Mozilla should do:

 - Display the redirected site (mozilla.org) in the browser pane. (This
satisfies the RFC.)
 - Display the original URL (aaronsw.com) in the URL bar; bookmarking should
also use this URL. (This satisfies CUAP.)

It's unclear to me what should happen when the user follows a link. I think the
safest thing to do is use the redirected URL (mozilla.org) as the base URL.

Comment 12

[Bradley Baetz (:bbaetz)]

Grr, crashed as I was submitting.

Anyway, what I was saying was basically that the two things are unrelated.

the w3c cuap says that if we get a 307, then bookmarking/session history/etc
should still refer to the original url.

However, doing this by having the urlbar show the original uri strikes me as a
potential security flaw, because if I could get bigCorp.com to redirect me to
mysite.com, then I could make it look as if the data was from their site.

The rfc2616 requirement applies for non HEAD/GET only. This is possibly because
of the risk of POSTing data to antoehr site, or maybe because POST bodies may
not be redirected, or maybe even because POST is non-idempotent, and its
imnpossible to distinguish between the cases:

a) first POST does something, redirects to a 'thank you' page
b) first POST redirects, second page handles teh POST
c) both pages handle the POST, and so you buy your item twice.

That one seems to most likely to me, but I have no way of knowing.

Comment 13

[Tom Mraz]

> However, doing this by having the urlbar show the original uri strikes me as a
> potential security flaw, because if I could get bigCorp.com to redirect me to
> mysite.com, then I could make it look as if the data was from their site.

It would be a security problem of the bigCorp.com website not Mozilla's.
Any bigCorp.com should have web developers/admins good enough to not allow
any malicious attacker to change their web server to redirect to other site.

Comment 14

[Darin Fisher]

ah... the summary of this bug threw me off.  (our cache validation logic does
the right thing when you load a temporary redirect a subsequent time, but that's
not what this bug is about.. doh!)  this bug is about the URL bar and any other
UI that shows the current URL.  according to the recommendation, the UI should
show the original URI when a redirect is temporary.  hmm... that makes good sense.

-> url bar

Comment 15

[Anthony DeRobertis]

If this is implemented, can there be a way to turn it off? It'd be quite a mess
for web authors to be seeing the wrong URL in the bar.

Or, at least, there needs to be some way to see what the actual URL is.

Comment 16

[Aaron Swartz]

What do you mean by the "wrong URL"? The whole point of this is so that the user
will see the right URL (the one they should link to and bookmark). I can see why
geeks might want to know where they were redirected to, but this should be
pretty obvious from following links.

Comment 17

[Josh Birnbaum]

*** Bug 227538 has been marked as a duplicate of this bug. ***

Comment 18

[Benjamin Otte]

Is any work done on this bug?

In recent times a lot of web sites send a 302 when for images if the referer doesn't match. It would be nice to be able to reload the URL without easier than going back and copying the image url.
An example for this is http://www.gutenberg.org/files/19585/19585-h/images/fig295.jpg which I just stumbled across.

(Also note that you have no way of getting the correct image once you got the wrong one without clearing the cache due to bug 89419 unless you clear the cache.)

Comment 19

[WulfTheSaxon [:Wulf]]

I agree with Anthony in comment 15 in that there should be a way to view the page's actual/redirected URL. However, I don't think a preference to disable showing the original URL is called for. A line in Page Info would make the most sense to me.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Comment 12 paragraph 4 seems right on the money to me.  I can _almost_ see showing the pre-redirect URI in the url bar if the redirect is same-origin.  However note that the in-page DOM info will have to be the post-redirect URI, and in particular the base URI, principal, etc, etc has to be the post-redirect URI.  So this seems like a pure UI issue, not a core issue, right?  Which is why it's in the component it's in...

Personally, I think this should be wontfixed.  The RFC is more or less out of touch with the way this stuff is being done in the real world, unfortunately.  :(

Comment 21

[David Wood]

I would *not* like to see this wontfixed.

Providing some mechanism in the UI to allow a user to see both the URL they attempted to resolve and the URL of the representation they were presented with is an important use case for Persistent URLs (PURLs) and other resolvable persistent identifier schemes that redirect.

Failure to address this bug with a UI change hampers the ability of the persistent identifier community to advertise bookmarkable URLs.  This has significant negative impact on that community, which includes the US Federal Depository Libraries as well as many other government, commercial, academic and non-profit organizations attempting to manage URL resolution for the purposes of providing persistent addresses.

Comment 22

[Boris Zbarsky [:bzbarsky]]

I'm fine with having a way to retrieve the original URL the user tried to resolve (which we DO have available internally, and the UI could surface it however it wants to).  I just don't think it should be in the url bar.