The dot after the TLD represents the root domain. From right to left, URLs read from least to most specific. Root -> TLD -> domain -> subdomain (eg www). The root domain is almost always left out, because it’s always the same and its presence is implied. But if you include it explicitly, it is a distinct URL.
So idk how bloomberg.com works under the hood so I can’t specifically explain this case, but rules that match URLs won’t necessarily see the two versions as identical. This is actually something worth testing your own sites against, to make sure including the root domain doesn’t do something dumb like bypass authentication or whatever.
Edit: also, forgive me if I’m explaining things you already know w/ regard to the root domain and stuff.
This is 50% of the reason, the other half is that all the tracking/ad requests hit an API endpoint on bloomberg.com (no dot at the end), which is now a separate origin as far as the same-origin policy is concerned. But the code is not expecting this to be the case, and doesn't set any CORS headers on the response, and the browser denies access to the response data.
This breaks the ads but also breaks any interactive charts, etc. that need data from the API.
New to me and I've been programming web for quite a while. I've only ever seen that final "." in DNS records, it never occured to me that it would affect logic within the site.
The trailing "." becomes practically important if you have a client that believes in DNS search suffixes (yuck!). I imagine it might have some effect in this particular case if the user-agent includes the dot in the "Host" HTTP request header and it thus evades some non-canonicalizing layer of Bloomberg's paywall thing, while still being a perfectly okay request to the rest of the chain.
You know what’s also missing if you go to bloomberg.com./? All of the ads, and the animated stock ticker. I’m on mobile so didn’t dig into it further, but I bet that all JS loaded on request from another domain (probably including the paywall) is absent or broken.
The site itself loads fine though, because DNS still works and whatever routing layer in their app probably doesn’t care about the domain, just the path that follows it.
I once got a verbal C&D from a Novell web dev because they answered to any domain and I pointed (as a joke) a domain to their IP. Google ended up indexing, and customers were asking what 'reallystrangedomain.com' was when they searched for Novell error messages.
They asked me to stop 'mirroring' their content, and didn't understand I was just pointing my domain to their servers. I stopped, but part of me didn't want to.
It shouldn't. It is the fault of hacky protocols like HTTPS that conflate routing with identity. If we had DNSSEC and IPSEC from the beginning, it wouldn't have been necessary to do it on application level.
I tried it and it only gives me a separate counter (i.e. 3 free articles on "bloomberg.com." in addition to the ones on "bloomberg.com".) This makes me suspect local storage or cookies.
So idk how bloomberg.com works under the hood so I can’t specifically explain this case, but rules that match URLs won’t necessarily see the two versions as identical. This is actually something worth testing your own sites against, to make sure including the root domain doesn’t do something dumb like bypass authentication or whatever.
Edit: also, forgive me if I’m explaining things you already know w/ regard to the root domain and stuff.