Cannot use port number in URL to embed media in post

In order to allow my users to host videos, audio files, etc. that they embed in Discourse posts, I have set up an Apache server running alongside the Nginx that runs Discourse. The Apache server runs on port 8008 for http: and port 591 for https: (IANA ports reserved for http-alt). This works fine and content on the server is accessible from browsers by specifying the port number in the URL, for example:

But if you try to embed this URL in a Discourse post, it fails with:

Sorry, we were unable to generate a preview for this web page, because the server ‘’ could not be found. Instead of a preview, only a link will appear in your post.

If I run tcpdump and monitor DNS traffic, I see nothing being sent when it rejects this URL. It is rejecting it without ever making a DNS query. If I change the port number in the URL to 443, the default for https:, it makes the DNS query normally but the embed fails, of course, because the Apache server is not listening on that port and the Discourse server does not know what to do with the URL. I have seen nothing in the Discourse documentation that indicates embed URLs may not specify a port number.

Looking through the source code, I found a test in function validate_uri_format at line 362 of lib/final_destination.rb which reads:

    return false if @uri.scheme == 'https' && @uri.port != 443

which appears to reject an https: URL that uses a port other than 443. This seemed to explain what I was seeing, so I commented out this line, but it made no difference at all, even after I restarted Discourse. When the post appears on the site with the embed turned into a text link, clicking the text link shows the video correctly, so the only problem is failing to recognise it as an embed and wrapping the inline player around it.

My questions are, at this point:

  • Are non-standard port numbers intended to work on URLs for embeds in Discourse posts?
  • If so, what is causing these URLs to be rejected?
  • Is there any way to get them to work?

There was a discussion here in March 2017 about this issue in these two posts:

which implied the problem had been fixed, but it does not work today on 2.9.0.beta10.

Thanks for any insights and/or assistance in this matter.