Skip to content

custom protocol parse result is different from chrome and firefox #44476

Closed
Closed
custom protocol parse result is different from chrome and firefox#44476
Labels
whatwg-urlIssues and PRs related to the WHATWG URL implementation.

Description

@loynoir
loynoir
opened on Sep 1, 2022

Version

v18.7.0 v16.16.0

Platform

alpinelinux and archlinux

Subsystem

No response

What steps will reproduce the bug?

Node

> new URL("sindre://www.sorhus.com").protocol
'sindre:'
> new URL("sindre://www.sorhus.com").host
'www.sorhus.com'
> new URL("sindre://www.sorhus.com").pathname
''

Google Chrome 92

> new URL("sindre://www.sorhus.com").protocol
"sindre:"
> new URL("sindre://www.sorhus.com").host
""
> new URL("sindre://www.sorhus.com").pathname
"//www.sorhus.com"

Mozilla Firefox 90

> new URL("sindre://www.sorhus.com").protocol
"sindre:"
> new URL("sindre://www.sorhus.com").host
""
> new URL("sindre://www.sorhus.com").pathname
"//www.sorhus.com"

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

No response

What do you see instead?

> new URL("sindre://www.sorhus.com").host
'www.sorhus.com'
> new URL("sindre://www.sorhus.com").pathname
''

Additional information

Related background story issue

sindresorhus/normalize-url#140

sindresorhus/normalize-url#147

Related background story

To answer Can I use version 7 in the browser?

I fork sindresorhus/normalize-url to loynoir/normalize-url

In that fork, I added real browser test using karma.

And found browser falling case, but it's ok in node

t.is(normalizeUrl('sindre://www.sorhus.com'), 'sindre://sorhus.com');

Seems root cause is

Node

> new URL("sindre://www.sorhus.com").protocol
'sindre:'
> new URL("sindre://www.sorhus.com").host
'www.sorhus.com'
> new URL("sindre://www.sorhus.com").pathname
''

Google Chrome 92

> new URL("sindre://www.sorhus.com").protocol
"sindre:"
> new URL("sindre://www.sorhus.com").host
""
> new URL("sindre://www.sorhus.com").pathname
"//www.sorhus.com"

Mozilla Firefox 90

> new URL("sindre://www.sorhus.com").protocol
"sindre:"
> new URL("sindre://www.sorhus.com").host
""
> new URL("sindre://www.sorhus.com").pathname
"//www.sorhus.com"

Activity

loynoir
changed the title [-]custom protocol parse result pathname is different from chrome and firefox[/-] [+]custom protocol parse result is different from chrome and firefox[/+] on Sep 1, 2022

targos commented on Sep 1, 2022

@targos
targos
on Sep 1, 2022
Member

whatwg-url seems to behave the same as Node.js, so it looks like a bug in web browsers?

Trott
added
whatwg-urlIssues and PRs related to the WHATWG URL implementation.
on Sep 1, 2022

Trott commented on Sep 1, 2022

@Trott
Trott
on Sep 1, 2022
Member

whatwg-url seems to behave the same as Node.js, so it looks like a bug in web browsers?

I haven't looked closely, but there's also something in the spec about how browser implementations are supposed to do more steps than non-browser implementations, so the difference in behavior might be due to that.

Trott commented on Sep 1, 2022

@Trott
Trott
on Sep 1, 2022
Member

Here it is:

Non-web-browser implementations only need to implement the basic URL parser.

I haven't looked at the steps in the parser to determine if this is or isn't a bug, but there is a good chance this is an expected divergence between web browsers and non-web-browsers.

Trott commented on Sep 1, 2022

@Trott
Trott
on Sep 1, 2022
Member

@nodejs/url

lpinca commented on Sep 1, 2022

@lpinca
lpinca
on Sep 1, 2022
Member

Deno and Safari 15.6.1 work like the Node.js and the reference implementation of the WHATWG URL.

$ deno
Deno 1.25.0
exit using ctrl+d or close()
> new URL("sindre://www.sorhus.com")
URL {
  href: "sindre://www.sorhus.com",
  origin: "null",
  protocol: "sindre:",
  username: "",
  password: "",
  host: "www.sorhus.com",
  hostname: "www.sorhus.com",
  port: "",
  pathname: "",
  hash: "",
  search: ""
}
>

I think Chrome and Firefox are deviating from the spec for some reason.

F3n67u commented on Sep 4, 2022

@F3n67u
F3n67u
on Sep 4, 2022
Contributor

I think it is Chrome, Edge, and Firefox are deviating from the spec because they both fail the wpt test when parsing custom protocols like sc://:

  1. go to https://wpt.fyi/results/url/url-constructor.any.html?label=master&label=experimental&aligned&view=subtest
  2. search "Parsing: <sc://" and you will see all 22 tests parsing "sc://" failed in Chrome, Edge, and Firefox, but are passed in Safari.
anonrig
closed this as completedon Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    whatwg-urlIssues and PRs related to the WHATWG URL implementation.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions