[5.x] Fix static caching of requests with trailing dot in host

[Jade-GG]

Fixes #11504

I've added a quick check here that makes sure any requests with a trailing dot get cached in a separate folder, as well as a test case that makes sure that it works.

Alternatively, we could just not make it cache these at all? I'm not sure what the best approach here is.

[jasonvarga]

That's wild to me that the domain with the trailing dot works at all. I feel like this should be resolved at the server level using a rewrite rule.

This seems to work in nginx:

if ($http_host ~ "\.$" ){
    rewrite ^(.*) $scheme://$host$1 permanent;
}

[Jade-GG]

That's wild to me that the domain with the trailing dot works at all. I feel like this should be resolved at the server level using a rewrite rule.

This seems to work in nginx:

if ($http_host ~ "\.$" ){
    rewrite ^(.*) $scheme://$host$1 permanent;
}

Yeah it's very surprising, and the only reason we even know this is possible is because we actually had a website break due to someone visiting our website with such a trailing . at the end and triggering this caching bug that way.

I still feel like it's kind of awkward to semi-require an nginx config like this in every installation of Statamic. Do you think it'd be nicer to, instead of this, have a permanent redirect from Statamic itself?

[indykoning]

Domain names ending in dot are completely valid and documented separately in the RFCs
https://www.rfc-editor.org/rfc/rfc1035#:~:text=Domain%20names%20that%20end%20in%20a%20dot%20are%20called%0Aabsolute%2C%20and%20are%20taken%20as%20complete.

Domain names that end in a dot are called
absolute, and are taken as complete. Domain names which do not end in a
dot are called relative;

https://www.rfc-editor.org/rfc/rfc1034#:~:text=character%20string%20which%20represents%20a%20complete%20domain%20name%0A%20%20%20%20%20(often%20called%20%22absolute%22).%20%20For%20example%2C%20%22poneria.ISI.EDU.%22

a character string which represents a complete domain name (often called "absolute"). For example, "poneria.ISI.EDU."

Which is why DNS, Nginx and Laravel handle it instead of dropping or redirecting it.

I do think we'll want to fix this somewhere in Statamic, as this documented behavior is causing issues due to caching.
Most people implementing Statamic will most likely not know of this, or that they have to implement an Nginx redirect to prevent their cache from being poisoned.

The biggest problem is when cache is cleared, the homepage is cached with the . suffix. Every user navigating from the homepage will cause every subsequent cache to contain this . suffix, even when users are not navigating to the site with the . suffix

Which is why a couple possible solutions are:

• Disabling caching for any domain with the . suffix
• Saving caches created with the . suffix in another folder
• Redirecting domains with the . suffix to the domain without . in Statamic, this makes sure users can't accidentally misconfigure it.

However in both cases redirecting domains with the . suffix using either PHP or Nginx may cause issues for users explicitly wanting the "Absolute domain name"

[jasonvarga]

My issue is more that we shouldn't have to add handling like this to one specific feature. I'm sure there will be instances of other parts of the framework/cms that arise if you try to do stuff with a trailing dot.

You configure your APP_URL to be http://yoursite.com/ for example, not http://yoursite.com./ - why should both work?

I'd be more open to a middleware or something that redirects the trailing dot to the non-trailing dot URL.

Plus in this PR you are making the dot part of the path. I would probably expect Statamic to normalize yoursite.com./page and yoursite.com/page to be the same page, which it seems to already do. The dot is part of the host, not the path.

[indykoning]

That's absolutely fair and how most sites seem to solve the issue.
It's a very niche usecase which causes big problems when caching the wrong domain.

Most sites seem to deal with it by simply redirecting:

• https://youtube.com./
• https://github.com./
• https://bol.com./

And some large sites do actually break because they don't handle this:

• https://amazon.com./
• https://mediamarkt.nl./

I'll create a PR to implement a middleware removing the . from the host.

see: #11782