22714 - [RFE] enable updating of bookmarks on 301 permanent redirect

Status: VERIFIED DUPLICATE of bug 8648

(SeaMonkey :: Bookmarks & History, enhancement, P3)

Description

[Joe Pranevich]

Just a suggestion:

On pages that return a 301 (permanent redirect), it would be very useful to end
users to have a dialog box or similar mechanism where they could choose to
update their bookmarks.

For example, a user goes to foo.bar.com/ and the server issues a 301 response
code with a new url of baz.bar.com/. If the user used a bookmark to get to
foo.bar.com/, he or she may be interested in replacing the addresses in his/her
bookmarks with this "forwarding" address and a prompt could be employed. (A full
search on bookmarks would probably be a good idea, but possibly confusing.)

Comment 1

[Sean Richardson]

Changing Component from "Browser-General to "Bookmarks"; adding [RFE] to
summary. Changing summary from "permanent redirects and bookmark updating" to
"[RFE] enable updating of bookmarks on 301 permanent redirect".

This would need to be implemented both in page-loading and bookmark-handling
code, but the lead would need to be in the Bookmarks component.

There is also the question of how often 301 responses happen - on
media-corporate sites, I'm guessing it's very prevalent. A dialog box
each time could be annoying - this might be better controlled by a pref
for all occurances, if that is advisable.

Comment 2

[Mats Palmgren (inactive)]

See also bug 8648.

Comment 3

[don]

Hmmmm, this IS an interesting idea.  Thanks.

Comment 4

[Jesse Ruderman]

I'm confused. One post calls 301 a "permanent redirect", but another says "A 
dialog box each time could be annoying". Are these media/corporate sites using 
301 incorrectly?

Comment 5

[Joe Pranevich]

According to the HTTP specification, a 301 code is a permanent redirect. To my 
knowledge, it is not "exploited" however I have not investigated the issue. 

For example, you have a redirect to site.foo.com but the remote site issues a 
301 and soecifies that the new URL is newsite.foo.com. If you used a bookmark 
to get to site.foo.com, my idea was to change that bookmark to newsite.foo.com. 

If, for example, a site was issuing redirects from site.foo.com to 
site.foo.com/<date> (a news site, for example) Then it shouldn't (by the 
specification) use a 301 redirect. (It should use a temporary redirect, I think 
that is 302)

As for the "prompt each time" issue. That could be configurable. I don't think 
it's going to happen nearly as often as suggested.

Comment 6

[don]

Move to "Future" milestone.

Comment 7

[Kjetil Kjernsmo]

I think this is a really great idea, and it's kind of strange that it hasn't
been done. 

Also, I'd like to add that if 410 Gone is returned, then, the bookmark should be
removed. 

I don't know if a lot of user interaction is required in this process. I mean,
301 and 410 should be pretty straightforward according to HTTP1.1, links should
be updated or removed, respectively. I can't see that it is necessary to ask for
the user's approval, but of course, a configureable option is always a Good
Thing [tm]. Well, on second thoughts, the spec says about 410:
"Clients with link editing capabilities SHOULD delete references to the
Request-URI after user approval."

How about 303 See Other? Would that have any relevance in this context?

Comment 8

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 9

[Karl Ove Hufthammer]

For a simple test case, you could try:
http://home.no.net/huftis/mozilla.html

You will be redirected to:
http://home.no.net/huftis/mozilla/

Also note that we need to handle multiple redirects, so:
http://home.no.net/~huftis/mozilla.html

redirects to:
http://home.no.net/huftis/mozilla.html

which redirects to:
http://home.no.net/huftis/mozilla/

A bookmark pointing to:
http://home.no.net/~huftis/mozilla.html

should therefore be changed to:
http://home.no.net/huftis/mozilla/

Comment 10

[Marcia Knous [:marcia]]

Netscape Nav triage team: this is not a Netscape beta stopper.

Comment 11

[Garth Wallace]

A dialog, rather than an automatic change, would be useful in case a site is
hacked to redirect to something else. For example, if some script kiddie gets
into keenspot.com and redirects it to goatse.cx, I don't want that to be
permanently reflected in my bookmarks.

Comment 12

[timeless]

mstoltz: could we use a security privelege to handle trusting the server and 
showing the dialog? [that still leaves updating the bookmark urls]

Comment 13

[Mitchell Stoltz (not reading bugmail)]

timeless - I'm not sure what you mean. Why would we trust the server at all? How
is trust an issue here? I need to think about how this could be exploited, but I
think a dialog should do the trick. We should definitely not change the user's
bookmarks without confirmation; I know I wouldn't want my browser to do that,
whether the link is 301'd or not.

Comment 14

[Karl Ove Hufthammer]

> We should definitely not change the user's
> bookmarks without confirmation;

Why not? When you visit a Web page with a 301 redirect (*Permanently* moved), 
you're always redirected. This probably happens *several times* each day 
(e.g. 'www.dmoz.org --> dmoz.org' and 'www.yahoo.no --> no.yahoo.com') and 
you're never asked if you want to accept it -- it just happens automatically.

Comment 15

[Mitchell Stoltz (not reading bugmail)]

Yes, but currently the redirect doesn't change the user's configuration at all.
We should confirm the modification of the user's bookmarks file, not the
redirect itself. Maybe the user has a good reason for pointing their bookmark at
the old link and would like to keep it there - we shouldn't make assumptions.

Comment 16

[Karl Ove Hufthammer]

> Maybe the user has a good reason for pointing their
> bookmark at the old link 

I still disagree. The user *will* never have any reason for pointing his/her 
bookmark to an outdated link which is permanently moved.

Also, HTTP 1.1 <URL: http://www.w3.org/Protocols/rfc2068/rfc2068 > says 
(regarding 301):

   Clients with link editing capabilities SHOULD
   automatically re-link references to the Request-URI to one or more of
   the new references returned by the server, where possible.

But note, this only goes for 301 Moved Permanently. For 302 Moved Temporarily:

   Since the redirection may be altered on occasion, the client SHOULD
   continue to use the Request-URI for future requests.

Comment 17

[Garth Wallace]

Reread my earlier comment. Rejecting a bookmark change would be useful in case 
of hacked redirects.

Comment 18

[Mitchell Stoltz (not reading bugmail)]

Automatically modifying the user's local data or configuration without
confirmation is Bad. That's my final word on the subject. Add this feature if
you want, but present a confirmation dialog.

Comment 19

[Claudius Gayle]

what mitch said. After reading the RFC at 10.3.2; you can automatically re-link all you want,
but it does not preclude us from putting up a confirmation dialog first. NO need to act like
these things are mutually exclusive. It's poor manners to change user entered data w/o
permission.

Comment 20

[Karl Ove Hufthammer]

OK, but can we please have 'Don't show this dialog in the future' checkbox (or 
something similar)?

Comment 21

[Garth Wallace]

Bug #8648 is very similar to this one...possible dup or dependency?

Comment 22

[Blake Ross]

-> ben

Comment 23

[Ben Goodger (use ben at mozilla dot org for email)]

This sounds like a variation on a bug asking for something similar for META 
redirects. 1.0. 

Comment 24

[Ben Goodger (use ben at mozilla dot org for email)]

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Comment 25

[Paul Chen]

permanent redirects were mentioned in 8648, marking dup

*** This bug has been marked as a duplicate of 8648 ***

Comment 26

[Claudius Gayle]

VERIFIED Dupe