Closed Bug 22714 Opened 22 years ago Closed 20 years ago
[RFE] enable updating of bookmarks on 301 permanent redirect
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.
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.
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]
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?
Assignee: vishy → ben
This sounds like a variation on a bug asking for something similar for META redirects. 1.0.
Status: NEW → ASSIGNED
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
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.