Closed Bug 48200 Opened 24 years ago Closed 24 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: 24 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: 24 years ago → 24 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: