New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 867766 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 3
Type: Bug



Sign in to add a comment

[Web compat] URL parser doesn't escape spaces in non-special schemes

Project Member Reported by mgiuca@chromium.org, Jul 26

Issue description

Chrome Version: 68
OS: All

What steps will reproduce the problem?
From JS console:

> new URL("http://example.com/foo bar").href
> new URL("fhqwhgads://example.com/foo bar").href

What is the expected result?
> new URL("http://example.com/foo bar").href
"http://example.com/foo%20bar"
> new URL("fhqwhgads://example.com/foo bar").href
"fhqwhgads://example.com/foo%20bar"

What happens instead?
> new URL("http://example.com/foo bar").href
"http://example.com/foo%20bar"
> new URL("fhqwhgads://example.com/foo bar").href
"fhqwhgads://example.com/foo bar"

The expected behaviour is seen in Firefox, and by spec: https://url.spec.whatwg.org/#path-state the path state doesn't treat non-special URLs any differently other than not treating '\' as a path separator. It uses the same percent encode set.

Note: In fact all of the other path-percent-encode-set characters ("<>`{}) also do not encode correctly in Chrome, but also don't encode in Firefox, so it's less clear cut that the spec is correct in this case.

Apparently this affects GURL as well ( https://crbug.com/847039#c52 ).
 
Status: Available (was: Untriaged)
The URL API (and other web-exposed URL-related APIs) use KURL under-the-hood. KURL and GURL use the same parser and canonicalisation. In most cases we can't change one without the other.

Sign in to add a comment