Closed Bug 1708581 Opened 4 years ago Closed 4 years ago

Percent-encoded alphanumeric characters in URL display as their decoded characters, but are sent percent-encoded still

Categories

(Firefox :: Address Bar, defect)

Firefox 88
defect

Tracking

()

RESOLVED DUPLICATE of bug 1486664

People

(Reporter: bugzilla.mozilla, Unassigned)

Details

Attachments

(1 file)

Attached file examples_firefox.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Into the address bar, enter a URL whose path contains a percent-encoded NON-special character, e.g. an ASCII letter "X": http://example.com/%58

Actual results:

Address bar shows "http://example.com/X", but "/%58" is sent to the server.

Expected results:

It should not be possible for URLs which are displayed as identical to send different data to the server. The address bar should uniquely reflect what is sent to the server. The address bar should show "http://example.com/X", and "/X" is sent to the server; or the address bar should show "http://example.com/%58", and "/%58" is sent to the server.

There are further inconsistencies with the location shown in the bottom left of the window when you hover over an anchor tag with certain percent-encoded special characters. E.g.

<a href="http://localhost:8000/%61%2f%62%3f%78%3d%58%26%79%3d%59">link</a>

When hovered, Firefox shows the location as "http://localhost:8000/a/b?x=X&y=Y".
When clicked, the address bar shows "http://localhost:8000/a%2fb%3fx%3dX%26y%3dY", but the server is actually sent the location "/%61%2f%62%3f%78%3d%58%26%79%3d%59". Hover displays all the characters decoded; address bar keeps the %2f (/), %3f (?), %3d (=), and %26 (&) as the %-encoded chars which are actually sent to the server, but misleadingly shows letters but sends them %-encoded.

If the page does not set a title, the default shown by Firefox seems to be the location that was actually sent to the server.

(For ease of seeing exactly what the links in "examples_firefox.html" are sending, you can run "php -S 127.0.0.1:8000 -t ." from a folder containing only that html file. PHP's built-in web server doesn't do any %-decoding magic that interferes with seeing what the browser is sending, and it echoes it back in the 404 page it generates.)

This does not appear to affect Firefox on Android. The bug does affect Firefox Nightly 90.0a1.

Note that the anchor tags in the examples_firefox.html attachment do not include the protocol and host prefix, so in the online view of the file, hosted on bug1708581.bmoattachments.org, they generate 302 redirects when clicked, and these redirects hide the discrepancy between the address bar and what is sent to the server.

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Address Bar

Per RFC 3986, Section 6.2.2.2. Percent-Encoding Normalization:

The percent-encoding mechanism (Section 2.1) is a frequent source of
variance among otherwise identical URIs. In addition to the case
normalization issue noted above, some URI producers percent-encode
octets that do not require percent-encoding, resulting in URIs that
are equivalent to their non-encoded counterparts. These URIs should
be normalized by decoding any percent-encoded octet that corresponds
to an unreserved character
, as described in Section 2.3.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: