Problems parsing udp:// URLs

From Valentin Gosu, in vlc-devel

Hi VLC developers,

I work on the Firefox networking stack. Recently Firefox (and Chrome) switched our URL parsers for non-special schemes to be more in line with the URL Standard [1]. However this caused issues for VLC users, when clicking udp:// links that are supposed to be opened in VLC [2]. For now we've added an exception for udp URLs, but some webdevelopers are using the udp scheme for other purposes [3]

We would like to remove the exception for udp URLs, and let them be parsed according to the URL standard. Is it possible to change the way VLC parses udp URLs [4] so that it still works if the @ character isn't present?

For example, for udp://@10.0.0.2:1234 the URL parser will remove the @ and turn it into udp://10.0.0.2:1234 Another case that needs to be addressed is udp://@:1234 as it currently fails to parse with the URL standard [5].

Thanks!

• [1] https://url.spec.whatwg.org/
• [2] 1949195 - Firefox removes at sign (@) from UDP links for VLC video player - https://bugzilla.mozilla.org/show_bug.cgi?id=1949195
• [3] 1954766 - URL does not parse hostname for udp urls
• [4] https://docs.videolan.me/vlc-user/desktop/3.0/en/advanced/streaming/udp_url.html
• [5] https://jsdom.github.io/whatwg-url/#url=dWRwOi8vQDoxMjM0&base=YWJvdXQ6Ymxhbms=

changed milestone to %4.0

added Component::Core: Input label

changed the description

I have mixed feelings here as that would break a behaviour that's been there for decades and therefore a lot of documentation and scripts.

I don't really get what we're supposed to do on the VLC side.

In the general case, the @ separates the source and destination adresses and/or ports. We can't simply remove it.

Likewise we can't simply require a valid address in front of the port number. That would just break existing scripts and playlists, and fix nothing.

The only thing that we could do is change the behaviour if the @ is absent. The current syntax means the address is the source, but some people would want it to be the destination. This is already the case for rtp:// IIRC, and is probably a more common scenario. But still as @typx noted, this will break existing scripts too.

Closing based on previous comments. Problems parsing URL in web browsers have nothing to do with VLC (at least since we no longer provide a web plugin).

closed

added Status::not VLC label

Thank you for your feedback. I just wanted to bring this to your attention and make a note that all browsers are switching their URL parsing behaviour, so these URLs will stop working - or at least will not do the expected thing when opened in VLC. I wasn't suggesting breaking behaviour, but instead maybe introducing special handling that would allow old URLs to work.

Thanks for considering this issue, and for all the great work (I'm a big fan of VLC).

As far as VLC is concerned, these "URLs" stopped working when browsers stopped support NPAPI plugins, so I don't really get the point here. Indeed, these pseudo-URLs don't do anything in my Firefox, or rather they trigger the search engine as any non-URL input.

I can only guess that some third-party extensions handle those, but if so, failing to translate correctly between the web browser and VLC is their bug.

I think you need to have the OS use VLC to open the udp:// scheme - not sure exactly what does that.

In any case, thank you for the background. I didn't know the scheme is no longer supported. We'll proceed remove the exception in Firefox within the next week or so.