1429786 - URI reserved characters []!'()* get decoded in the location bar but not re-encoded when the URL is submitted

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[robingrindrod]

Attachment: test.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180103231032

Steps to reproduce:

1. Open the attached test page (or any form with text input and get method)
2. Enter any of the following characters in the text box: []!'()*
3. Submit the form
4. Click on the location bar to highlight the URL
5. Hit enter to submit the URL


Actual results:

When the form is submitted the characters get correctly percent encoded. They are then show decoded in the location bar. When the URL is resubmitted the characters are not encoded resulting in different data being sent to the server for what appears to the user to be the same URL.


Expected results:

Both requests should result in the same query string getting sent to the server.

Comment 1

[Michał Gołębiowski-Owczarek [:mgol]]

This is a significant problem in Angular apps which use parens to define auxiliary routes, see https://angular.io/api/router/Routes

Since PR https://github.com/angular/angular/issues/10280 landed in Angular it's possible to use parens inside of regular URL segments if they're percent-encoded. An example or URLs we have in our app:

https://example.com/brand/Google_%28Brand%29

On this page you can open a popup resulting in a URL:

https://example.com/brand/Google_%28Brand%29(popup:explore)

It works wonderfully in Chrome & Opera. In Firefox location.href remains equal to the provided URL but URL shows decoded parens. I thought it'd still work as if you copy the URL from the address bar & paste in a text editor the original URL is pasted with properly decoded some parens & properly encoded others. However, if you then paste such a URL in Firefox, it decodes them & the invalid URL is loaded, breaking the Angular app.

Comment 2

[hooptie45]

I'm also getting client complaints about this issue, except the urls were from Thunderbird emails.

Comment 3

[Jim Martens]

I can confirm that this problem still occurs. I have verified with Wireshark that Firefox does not encode those symbols in the URL. Spring Boot returns correctly with 400 status code. Apache/Tomcat seem to be more lenient here but Firefox should not send them decoded in the first place.