Closed Bug 48200 Opened 25 years ago Closed 25 years ago

Incorrect base URL used on redirected pages

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dp, Assigned: gagan)

References

Details

(Whiteboard: [dogfood+])

Attachments

(1 file)

Patch to use GetOriginalURI only for chrome URLs
1.12 KB, patch
Details | Diff | Splinter Review
This has happened to me many times now. I would click on a link or do a form post and the url beta2 goes to would be missing a component. If I do it again, it would work. Like now: I went to http://lxr.mozilla.org , pasted some text and hit [Text Search]. The url this resolved to the first time around was: http://lxr.mozilla.org/search?string=09f689e0-b4da-11d2-a68b-00104bde6048 instead of http://lxr.mozilla.org/seamonkey/search?string=09f689e0-b4da-11d2-a68b-00104bde6048 But then, I try again, it works now.
Nominating for beta3.
Keywords: nsbeta3
Happens with Linux M18 2000-08-08-20 also. Tested on http://www.w3.org/TR/html4/ . Clicking on the link for "Tables" the first time takes me to http://www.w3.org/TR/struct/tables.html . Clicking the second time takes me to http://www.w3.org/TR/html4/struct/tables.html This is dogfood.
*** Bug 48795 has been marked as a duplicate of this bug. ***
I can't provide a reliable test case, but I can definitely vouch for the presence of this bug. I have mostly seen it shortly after user authentication, esp. with Apache 1.3.13-dev, although I imagine it happens with other servers too.
The w3c.org page is a reliable testcase.
*** Bug 48843 has been marked as a duplicate of this bug. ***
not seen on win95
Keywords: pp
The problem can be reproduced by going to: http://lxr.mozilla.org/seamonkey instead of http://lxr.mozilla.org/seamonkey/ The former HTTP-redirects to the latter. (I think it may be that once the page is cached in session history as the latter things are OK.) I really think I've seen a bug on this before, but I can't find it. This is not at all specific to form submission - when the page is loaded by the first URL, all the relative URLs on the page are wrong (e.g., the "mozilla/" link is to http://lxr.mozilla.org/mozilla/ instead of http://lxr.mozilla.org/seamonkey/mozilla/ .
Summary: Sometimes we form the wrong url → Incorrect base URL used on redirected pages
See also: bug 32359, bug 48385 Exactly the same as this bug (I think): bug 48885, bug 48927. Considering the bug#s, this seems like a regression.
*** Bug 48927 has been marked as a duplicate of this bug. ***
This bites me all day while I'm trying to testcase, triage, and dupe bugs. Nominating for dogfood consideration. Note that duplicate bug 48310 was already approved for dogfood+. Also dupes are reported on other platforms -> all/all. Please when trying to reproduce, carefully note trailing slashes. My initial reproduction steps should have been these: 1) http://www.w3.org/TR/html4 2) Click on "Tables"
Keywords: pp → dogfood
OS: Linux → All
Hardware: Other → All
*** Bug 48310 has been marked as a duplicate of this bug. ***
Old bugs on the issue: bug 3134, bug 10647 Still open: bug 27048. [is this a dup?] Related: bug 30271
Keywords: dogfood → pp
OS: All → Linux
Hardware: All → Other
Keywords: pp → dogfood
OS: Linux → All
Hardware: Other → All
*** Bug 48405 has been marked as a duplicate of this bug. ***
carrying over dogfood+ from bug 48310. Here's leger's comment from when she marked it dogfood. >------- Additional Comments From leger@netscape.com 2000-08-14 14:29 ------- > >Putting on [dogfood+]...we need this fixed for daily work. ckritzer, how does >this look on all platforms with Aug 14 builds?
Whiteboard: [dogfood+]
This bug is still present in linux 2000081505.
Seems to have been fixed in MacOS 2000081504.
Yet, the URL displayed in the task bar below upon mouseover (ex.1) and the URL in the location window after clicking the linke (ex.2) are somewhat weird. 1)http://www.w3.org/TR/html4#minitoc 2)http://www.w3.org/TR/html4/#minitoc
Wrong. The bug is still present in Mac OS 2000-081504. Sorry for the confusion. The link only worked when the browser went back to the page from another page whereupon the thrash was added to the URL in the location window.
*** Bug 49282 has been marked as a duplicate of this bug. ***
*** Bug 48674 has been marked as a duplicate of this bug. ***
*** Bug 49353 has been marked as a duplicate of this bug. ***
*** Bug 49321 has been marked as a duplicate of this bug. ***
*** Bug 49264 has been marked as a duplicate of this bug. ***
*** Bug 48527 has been marked as a duplicate of this bug. ***
Could be the good old problem that we are not updating the url after a redirect (from http://host/path to http://host/path/)
yup thats what it is... am looking to see what caused the regression.
*** Bug 48636 has been marked as a duplicate of this bug. ***
*** Bug 49599 has been marked as a duplicate of this bug. ***
Let's make sure and check all of these dupes when the bug resolves. Almost all of them have given the URLs where they had the problem.
*** Bug 49344 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
I can't seem to locate what caused the regression but the problem here is essentially that on a redirected page all the links carry the the baseURI of the original page and hence a ton of things break. Necko is doing the right thing here but its just that we don't get the right baseURI to make abs them correctly. Ccing all the relevant people who might have a clue as to what changed in docshell that caused this. mscott any ideas?
*** Bug 49488 has been marked as a duplicate of this bug. ***
Finally figured out whats going on here. hyatt's recent checkins to change GetURI to GetOriginalURI (in nsDocument::Reset()) broke the mechanism. I have a fix but this is in hyatt's code so I have to get it reviewed from him. Will attach the diffs here.
Keywords: patch
*** Bug 22886 has been marked as a duplicate of this bug. ***
*** Bug 48270 has been marked as a duplicate of this bug. ***
*** Bug 49711 has been marked as a duplicate of this bug. ***
*** Bug 49552 has been marked as a duplicate of this bug. ***
Blocks: 49547
*** Bug 49736 has been marked as a duplicate of this bug. ***
fix checked in. r=hyatt
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 49798 has been marked as a duplicate of this bug. ***
*** Bug 49795 has been marked as a duplicate of this bug. ***
Blocks: 49460
Looking at build 2000082208, the fix appears to have corrected the immediate problem, but may have introduced a new one. Prior to this build, the URL displayed in the navigation toolbar was being changed to the redirected value (which I believe is the desired behaviour). But with this build, the displayed URL remains in its original form, rather than the redirected one. For example, if I enter the URL "http://www.ento.csiro.au/ice2004", the page now renders correctly, but the URL in the navigation bar continues to read "http://www.ento.csiro.au/ice2004", rather than "http://www.ento.csiro.au/ice2004/" (that trailing backslash is the bit that should change...)
Yes, I see this new problem as well. Reopening and modifying summary line from: Incorrect base URL used on redirected pages to Incorrect URL displayed for redirected pages
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Incorrect base URL used on redirected pages → Incorrect URL displayed for redirected pages
Nope that is a separate bug (I have reopened bug 30783) and am setting the status back to what the original problem was. And closing this.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Summary: Incorrect URL displayed for redirected pages → Incorrect base URL used on redirected pages
verified Linux 2000082508 Win NT 2000082508
Status: RESOLVED → VERIFIED
*** Bug 50750 has been marked as a duplicate of this bug. ***
*** Bug 50284 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: