Skip to content

Bug in WHATWG URL parsing #41220

Description

@alexander-akait

Version

v16.13.1

Platform

Linux evilebottnawi 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

Code:

console.log(new URL("chrome-extension://__MSG_@@extension_id__/895c2722a512d5b2e333.png"))

output:

URL {
  href: 'chrome-extension://__MSG_%40@extension_id__/895c2722a512d5b2e333.png',
  origin: 'null',
  protocol: 'chrome-extension:',
  username: '__MSG_%40',
  password: '',
  host: 'extension_id__',
  hostname: 'extension_id__',
  port: '',
  pathname: '/895c2722a512d5b2e333.png',
  search: '',
  searchParams: URLSearchParams {},
  hash: ''
}

Then run the same code in browser (chrome):

URL {
  hash: ""
  host: "extension_id__"
  hostname: "extension_id__"
  href: "chrome-extension://extension_id__/895c2722a512d5b2e333.png"
  origin: "chrome-extension://extension_id__"
  password: ""
  pathname: "/895c2722a512d5b2e333.png"
  port: ""
  protocol: "chrome-extension:"
  search: ""
  searchParams: URLSearchParams {}
  username: ""
  [[Prototype]]: URL
}  

Look at username, they are different.

But if we will try firefox:

URL { href: "chrome-extension://__MSG_@@extension_id__/895c2722a512d5b2e333.png", origin: "null", protocol: "chrome-extension:", username: "", password: "", host: "", hostname: "", port: "", pathname: "//__MSG_@@extension_id__/895c2722a512d5b2e333.png", search: "" }
hash: ""
host: ""
hostname: ""
href: "chrome-extension://__MSG_@@extension_id__/895c2722a512d5b2e333.png"
origin: "null"
password: ""
pathname: "//__MSG_@@extension_id__/895c2722a512d5b2e333.png"
port: ""
protocol: "chrome-extension:"
search: ""
searchParams: URLSearchParams {  }
username: ""
<prototype>: URLPrototype { toJSON: toJSON(), toString: toString(), href: Getter & Setter, … }

Output is not the same as Node.js/chrome

Not sure it is real bug on Node.js, because we have three different outputs, or in specification, maybe we will find the answer here

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

Always

What is the expected behavior?

The same output

What do you see instead?

No response

Additional information

Original issue webpack/webpack#15012

Activity

  1. added
    whatwg-urlIssues and PRs related to the WHATWG URL implementation.
    on Dec 17, 2021
  2. jasnell commented on Dec 17, 2021

    @jasnell
    Member

    Node.js' output is the correct one here per the WHATWG spec.

  3. alexander-akait commented on Dec 17, 2021

    @alexander-akait
    Author

    @jasnell What is strange, because chrome uses these strange examples in docs https://developer.chrome.com/docs/extensions/reference/i18n/#overview-predefined, can you provide link in spec/on implementation which respect of handling this

  4. noahziheng commented on Jan 24, 2022

    @noahziheng

    @alexander-akait
    I found the description in WHATWG URL Spec at https://url.spec.whatwg.org/#authority-state.

    If U+0040(@) used twice in the URL, the first one will convert to %40 and handled with authority params(username:password).

    The browser like Chrome, Firefox may handle @@ in URL specially. Maybe this case can be handled in webpack specially with a PR, if Node.js need compatible with previous versions?

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