Closed Bug 22714 Opened 22 years ago Closed 20 years ago

[RFE] enable updating of bookmarks on 301 permanent redirect

Categories

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

x86
All
enhancement

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 8648
mozilla1.0

People

(Reporter: jpranevich, Assigned: paulkchen)

Details

(Keywords: helpwanted, Whiteboard: [ben-m5])

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.)
Assignee: nobody → slamm
Component: Browser-General → Bookmarks
QA Contact: nobody → claudius
Summary: permanent redirects and bookmark updating → [RFE] enable updating of bookmarks on 301 permanent redirect
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.
See also bug 8648.
Assignee: slamm → don
Target Milestone: M20
Hmmmm, this IS an interesting idea.  Thanks.
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?
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.
OS: Windows 98 → All
Move to "Future" milestone.
Target Milestone: M20 → Future
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?
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
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/
Netscape Nav triage team: this is not a Netscape beta stopper.
Keywords: nsbeta1-
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.
mstoltz: could we use a security privelege to handle trusting the server and 
showing the dialog? [that still leaves updating the bookmark urls]
Keywords: helpwanted
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.
> 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.
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.
> 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.
Reread my earlier comment. Rejecting a bookmark change would be useful in case 
of hacked redirects.
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.
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.
OK, but can we please have 'Don't show this dialog in the future' checkbox (or 
something similar)?
Bug #8648 is very similar to this one...possible dup or dependency?
Blocks: 8648
-> ben
Assignee: vishy → ben
This sounds like a variation on a bug asking for something similar for META 
redirects. 1.0. 
Status: NEW → ASSIGNED
Whiteboard: [ben-m5]
Target Milestone: Future → mozilla1.0
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Assignee: ben → pchen
Status: ASSIGNED → NEW
Depends on: 103610
permanent redirects were mentioned in 8648, marking dup

*** This bug has been marked as a duplicate of 8648 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
VERIFIED Dupe
Status: RESOLVED → VERIFIED
No longer depends on: 103610
Product: Browser → Seamonkey
No longer blocks: 8648
You need to log in before you can comment on or make changes to this bug.