Closed Bug 1234575 Opened 8 years ago Closed 8 years ago

Empty fragment ignored in URI of location header despite RFC 7231

Categories

(Core :: Networking, defect)

41 Branch
Unspecified
Windows
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox48 --- fixed

People

(Reporter: mozillabugzilla.20.mykro, Unassigned)

Details

(Whiteboard: [necko-backlog])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20151014143721

Steps to reproduce:

Requested from the server via POST: "document1.php#fragment"
Server answers with location header: "document2.php#"


Actual results:

Firefox requests via GET: "document2.php#fragment"


Expected results:

Firefox requests via GET: "document2.php#"

According to the new RFC 7231, section 7.1.2 (https://tools.ietf.org/html/rfc7231#section-7.1.2), user agents must inherit the fragment from the original resource. This is what Firefox does. But inheritance must not occur according to the RFC if a fragment is explicitly given by the location header. Firefox respects this rule if the fragment is not empty. But if the server redirects you to a new location with an empty fragment, Firefox still takes the old fragment. That means you cannot get rid of the fragment from the original resource.
Component: Untriaged → Networking
Product: Firefox → Core
Hi reporter,

Could you please provide a simplified testcase so that I can test your issue on my end?

Also please try to reproduce this on the latest release(43.0.3) and latest Nightly (https://nightly.mozilla.org/) and provide the results. When doing this, please try to reproduce with a new clean Firefox profile, maybe even in safe mode, as some of this issues may be caused by third party installed add-ons or custom settings(https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems).

Thanks,
Cipri
Flags: needinfo?(mozillabugzilla.20.mykro)
Hi Cipri,

It works also with an initial GET request, so it is really easy to reproduce.

Just create a resource that redirects you with a location header to a page with an empty fragment. For example create a file foo.php with PHP:

<?php
header("Location: test.php#");
?>

Now request "foo.php#bar" with Firefox. It SHOULD redirect you to "test.php#" according to the RFC, but Firefox takes you to "test.php#bar" instead, which is wrong.

I just tested in 43.0.1 in safe mode with an empty profile. Same result. I cannot test with a nightly build right now. Someone else will have to do that.

Best,
Christoph
Flags: needinfo?(mozillabugzilla.20.mykro)
Additional Information: IE 11 handles it correctly.

Best, Christoph
Hi Cristoph,

I've managed to reproduce this on the latest release(43.0) and latest Nightly(46.0a1). This testcase works correctly on Chrome and IE.

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151223140742

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160105030211

Considering this, I will mark this issue as New.
If anyone considers that the component is not the right one, please change it to a more appropriate one.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Windows
this looks like an easy webcompat fix.. valentin?
Flags: needinfo?(valentin.gosu)
Whiteboard: [necko-backlog]
Attachment #8725251 - Flags: review?(mcmanus) → review+
Flags: needinfo?(valentin.gosu)
https://hg.mozilla.org/mozilla-central/rev/2bb06f221cfe
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: