1954766 - URL does not parse hostname for udp: urls

Status: RESOLVED FIXED

(Core :: Networking, defect, P3)

Description

[danoftheroses]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

In console, type:

(new URL("udp://example.com.")).hostname 

Actual results:

Console evaluates this to ""

Expected results:

It should evaluate to example.com.

Comment 1

[danoftheroses]

This is closely related to https://bugzilla.mozilla.org/show_bug.cgi?id=1374505, which reported similar parsing issues for other non-special url schemes.
problems with UDP parsing were previously reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1572602 which may or may not be considered a duplicate.

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[danoftheroses]

It seems also this behavior can be corrected on about:config by setting network.url.simple_uri_unknown_schemes_enabled to false EVEN THOUGH udp is NOT listed in network.url.simple_uri_unknown_schemes.

I think this bug was caused by https://bugzilla.mozilla.org/show_bug.cgi?id=1889988.

Comment 4

[Valentin Gosu [:valentin]]

We shipped a remote settings config to allow udp URLs to be parsed with nsSimpleURI because of bug 1949195.
I'll reach out to VLC developers, and hopefully we can remove this exception.

Comment 5

[danoftheroses]

Ah okay. I see now why it's that way. According to spec a element has an internal URL record, despite the appearance of href being a string. It seems there's no need for Firefox to parse the URL at all rather than passing it on to the client application unchanged. https://html.spec.whatwg.org/multipage/links.html#api-for-a-and-area-elements

Still, I can't even reproduce bug 1949195; to be clear, I can see Firefox altering the URL in the fiddle to remove the @, but, at least on Windows 11, a clean install of VLC registers itself as a file handler for e.g. .mpeg4 files, but does NOT register itself as a handler for udp: URLs.

I think the URL handling association reported on the VLC forum is some custom thing, not built in to VLC itself:

We've got a web app that lets you click on an icon to launch a URL of the form "udp://@239.255.1.2:3456" to view that stream in VLC. As part of setting up each PC, we associate the udp URL scheme with VLC for this purpose.

Comment 6

[danoftheroses]

I was able to reproduce 1949195 on MacOS.

I also discovered that udp://:0@238.1.1.1:1234 works in VLC and survives a round trip through both Chrome and Firefox's URL parsing logic. According to VLC, ":0" is "any source address and port" whereas the URL spec parses it as credentials.

Comment 7

[Valentin Gosu [:valentin]]

Once we get a resolution from the VLC issue, we can remove the udp scheme from the exception list.

Comment 8

[Valentin Gosu [:valentin]]

Judging by https://code.videolan.org/videolan/vlc/-/issues/29090 and https://mailman.videolan.org/pipermail/vlc-devel/2025-March/143712.html I'm not sure there's a lot of interest in resolving this on the VLC side.

If no progress is made, I'll remove the udp exception from remote settings in two weeks.

Comment 9

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1949195

Comment 10

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1949195

Comment 11

[Valentin Gosu [:valentin]]

Just removed the udp scheme from the remote settings bucket.
Clients should update soon enough.