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)
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.
Updated•8 years ago
|
Component: Untriaged → Networking
Product: Firefox → Core
Comment 1•8 years ago
|
||
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
Comment 4•8 years ago
|
||
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
Comment 5•8 years ago
|
||
this looks like an easy webcompat fix.. valentin?
Flags: needinfo?(valentin.gosu)
Whiteboard: [necko-backlog]
Review commit: https://reviewboard.mozilla.org/r/37381/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/37381/
Attachment #8725251 -
Flags: review?(mcmanus)
Updated•8 years ago
|
Attachment #8725251 -
Flags: review?(mcmanus) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/2bb06f221cfee6f6ccc8c98f770b004c6197d459 Bug 1234575 - Empty fragment is ignored in URI of location header r=mcmanus
Flags: needinfo?(valentin.gosu)
Comment 9•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2bb06f221cfe
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in
before you can comment on or make changes to this bug.
Description
•