9040 - When a URL is redirected, the fragment ID is lost

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[bert]

When a server sends back a "301 moved permanently" in response to a given URL,
Mozilla will get the document from the new location, but will throw away any
fragment ID that was attached to the original URL.

Example:

    http://www.w3.org/TR/REC-xml-names#NT-NCName
and
    http://www.w3.org/TR/REC-xml-names/#NT-NCName

I expected the two to act the same, but only the latter scrolls to the indicated
target.

The HTTP 1.1 spec doesn't seem to say anything about this. Of the 12 browsers I
tested, only three (Amaya, Spyglass eMosaic, Hotjava) handled the fragment ID
the way I expected.

Comment 1

[Warren Harris]

Assigning to gagan.

Comment 2

[Gagan]

Bert: Which version were you checking this with?

Comment 3

[bert]

How do I find out? I know I used a viewer.exe dated 17-Mar-99 on WinNT (French,
v4.0 SP4). I just downloaded M8, and the behavior is still the same (I tried
both WinNT and Linux).

Comment 4

[leger]

Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)

Comment 5

[bert]

I've written a small Internet Draft about how I think HTTP should behave:
http://www.ietf.org/internet-drafts/draft-bos-http-redirect-00.txt

Comment 6

[Paul MacQuiddy]

bert, do you want to check this with the latest nightly builds (new networking
library!) at http://www.mozilla.org/binaries.html
And then bug gagan again if it doesn't work :-)

Comment 7

[leger]

Updating QA Contact

Comment 8

[Paul MacQuiddy]

this is still happening with necko

Comment 9

[Andreas Otte]

I have a patch for this, see attachement

Comment 10

[Andreas Otte]

Attachment: Patch to fix the problem

Comment 11

[Andreas Otte]

modified fix checked in ...

Comment 12

[Gagan]

thanks andreas.

Comment 13

[Tom Everingham]

Verified fixed in 9/29 builds, both cases work as desired.

Comment 14

[rpotts (gone)]

In order to fix bug #16418, I needed to remove the code from nsHTTPChannel.cpp
which copies over the Param and Query of the original URL into the redirected
URL.  Now, only the Ref is copied.  Is this still OK?

Comment 15

[Andreas Otte]

Please have a look at bug 9472. This bug was caused by not transfering the query
to the new location. It was fixed with my fix for this one, now it should fail
again. Bug 14946 was another version of this problem.

Comment 16

[leger]

Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.