Bug report: Multiple issues when including a trailing dot in Netlify-related hostname

Before I actually start this bug report, you might be wondering if it even makes sense to try to access https://www.netlify.com./ instead of https://www.netlify.com/. The short answer is, yes it does, it is supported by all major browsers, and the latter form is actually a relative form of the former. For more details on this topic, you may want to read this nice explanation, or refer directly to the standard RFC 2396 at section 3.2.2.

My configuration:

  • Default subdomain: debigare.netlify.app
  • Primary domain: www.debigare.com
  • Redirects automatically to primary domain: debigare.com

Problem: When accessing a Netlify site using the HTTPS scheme, if the URL hostname ends with a trailing dot, it generally does not work.

Examples:

  • https://www.netlify.com./ appear to work as expected.
  • https://netlify.com./ returns HTTP status code 503 with no body.
  • https://debigare.netlify.com./ redirects to https://debigare.netlify.app/ as expected, which itself redirects to https://www.debigare.com/ due to my _redirects rules.
  • https://www.netlify.app./ returns a TLS certificate that is only valid for *.netlify.com and netlify.com, causing the connection to fail.
  • https://netlify.app./ returns a TLS certificate that is only valid for *.netlify.com and netlify.com, causing the connection to fail.
  • https://debigare.netlify.app./ returns a TLS certificate that is only valid for *.netlify.com and netlify.com, causing the connection to fail.
  • https://www.debigare.com./ returns a TLS certificate that is only valid for *.netlify.com and netlify.com, causing the connection to fail.
  • https://debigare.com./ returns a TLS certificate that is only valid for *.netlify.com and netlify.com, causing the connection to fail.

Note that when I attempt to add www.debigare.com. or debigare.com as domain aliases as a workaround, I’m getting the error message “Invalid domain name”, which is a confusing error in this case since these are valid fully qualified domain names.

Interesting discoveries! I see what you are seeing in chrome, though oddly in curl the URL’s all work as intended.

I’ll ask our traffic & delivery developers to take a look next week when I get a chance, and give us their advice which we’ll relay to you.

You definitely should not try adding hostnames with an explicit dot to our config; that won’t affect anything for the better.

1 Like

Thanks! I previously confirmed with Chrome and Firefox that it was broken. Interesting that curl works.

I did a quick curl test with the --verbose flag enabled, and the logs don’t reference the trailing dot at all, which makes me suspect curl drops it before sending the request, hence why Netlify returns the correct TLS certificate with this client. I’ll investigate more and report the issue to the curl team if applicable when I have more time, but you may want to validate this on your side as well.

Note that I had preemptively added _redirects rules with trailing dots in hostnames, and haven’t run into any issues. Let me know if I should revert.

Hi, for the time being, you can leave the _redirect rules in place. I have filed an issue around URLs with a trailing dot that matches a redirect rule and we’ll update here if/when we have fixed the issue. Thanks for reporting the issue!

Hi @Dennis, I think there has been a misunderstanding. I have no idea if a trailing dot in the hostname of a _redirects file entry rule works or not. In fact, I have been working under the assumption that Netlify handles trailing dots in hostnames as if it was a completely different domain name from the non-trailing dot version while processing such rules.

The problem is that I can’t properly test if my assumption is correct or not with my current configuration, as my website uses preloaded HSTS, which triggers the HTTPS certificate error I described in my original post before any other redirect can be processed by normal web clients.

As such, the only issue that I’m aware of related to this is the one from my original post for which I’m not sure if @fool had the opportunity to follow-up on it yet or not.

We did get a bug filed for the appropriate team, but it will not result in any short-term changes in behavior as far as I know. We’ll follow up here if there are changes to report in the future!

1 Like

I just realized I made a small mistake in my original post that I can’t edit anymore. In the first paragraph, when I was comparing two example URLs, I wrote “and the latter form is actually a relative form of the latter” while I meant “and the latter form is actually a relative form of the former”.

If a mod could fix that both here and in the filed bug report if applicable, it would be appreciated. :slight_smile:

done, @SmashManiac! happy to assist.

1 Like