Closed Bug 1572602 Opened 5 years ago Closed 5 years ago

WHATWG URL class can't handle urls with non-standard protocols like udp://

Categories

(Firefox :: Untriaged, defect)

68 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1374505

People

(Reporter: feross, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36

Steps to reproduce:

  1. Execute the code new URL('udp://example.com:4000').port.
  2. It returns '' (empty string)
  3. This is wrong.

Actual results:

It seems that the udp: prefix confuses the URL object. This does not happen in Node.js or Safari. These browsers return '4000', as expected.

Certain protocols work fine (e.g. http, https, ftp).
Most other protocols don't work (e.g. udp, dweb, magnet, ipfs, ipns, dat)

Is there a whitelist of valid protocols? Why? This object is often used in place of a node.js-style shim like https://github.com/defunctzombie/node-url but we can't actually stop shipping this code to our users if Chromium's URL class rejects these perfectly valid URLs.

Note: The code new URL('udp://example.com:4000').port behaves differently in Chrome/Firefox vs. Node.js/Safari. It returns '' (empty string) in Chrome and Firefox, but it returns '4000' in Safari and Node.js.

Expected results:

The code new URL('udp://example.com:4000').port should return the string '4000'. Not '' (empty string).

In fact, quite a few of the other properties besides port are wrong. For example, hostname is also returned as '' (empty string).

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

Thanks for the pointer to the duplicate bug. I couldn't find it in search :/

You need to log in before you can comment on or make changes to this bug.