TYPO3: Unify top-level domain of dummy urls

[alexander-nitsche]

Currently there are numerous variants of top-level domains used in dummy urls of the TYPO3 documentation, among others:

• http://localhost
• http://example.com
• https://example.com
• http://www.example.com
• https://www.example.com
• http://example.org
• https://example.org
• https://www.example.org
• https://example.de
• https://www.example.de
• http://mydomain.de

To further improve consistency in the TYPO3 documentation, the same top-level domain should be used in all places. It is proposed to use

1. https://example.org
2. https://example.com
3. https://example.net

in that order: https://example.org as preferred domain, and https://example.com and https://example.net as alternatives if multiple domains are required within the same context. Preferring HTTPS over HTTP should be the default in current times. Dropping www. has become popular in recent times. Preferring .org over .com plays nice with the TYPO3 documentation being hosted at typo3.org and typo3.com being owned by typo3.org :)

[mbrodala]

As mentioned in Slack I'd also prefer hosts without www. and only add it if a specific example (e.g. cookies) requires it.

[alexander-nitsche]

For explicitly mentioning local development context i suggest to use

4. https://example.local

always.

[jonaseberle]

For explicitly mentioning local development context i suggest to use

4. https://example.local

.local was meant for that but has been unfortunately used in Bonjour/Zeroconf/Multicast and shouldn't be recommended any more.

There is https://www.ietf.org/rfc/rfc2606.txt which reserves .test, .example, .invalid, .localhost for self-created domains.

.localhost should not point to anything else than 127.0.0.x (as this has become an assumption for some legacy software). But Virtual Machines or docker in promiscuous mode can very well have other IPs than 127.0.0.x...

So I think the best recommendation is .test for a locally used domain. https://en.wikipedia.org/wiki/.test

[mbrodala]

First .dev was burned by Google enforcing HTTPS, now .local is burned by random companies/projects going ahead and relying on it. :facepalm:

[alexander-nitsche]

There is https://www.ietf.org/rfc/rfc2606.txt which reserves .test, .example, .invalid, .localhost for self-created domains.

Then let's choose example.example for local domains.

[alexander-nitsche]

seriously, i would be for example.localhost which is almost the same as example.local and verry verbose.

[jonaseberle]

Perfect. I couldn't find any reasons against example.example apart from that it looks confusing in docs 😆

[alexander-nitsche]

Hi @mbrodala , hi @jonaseberle , so should the local dummy domain be renamed from example.local to example.localhost?

[mbrodala]

I'm fine with anything which is obvious just from looking. Now that we have normalized everything to example.local it should be easier to change.

[jonaseberle]

I still prefer .test beacause it conveys the correct meaning and covers multiple cases for local installations. .localhost is ok for me, too. As long as it is not the error-prone .local ;)

[DanielSiepmann]

The RFC states which domains should be used within documentation already: https://datatracker.ietf.org/doc/html/rfc6761#section-6.5

Furthermore, the RFC states which ones should be used for localhost: https://datatracker.ietf.org/doc/html/rfc6761#section-6.3

Also .local is already defined: https://datatracker.ietf.org/doc/html/rfc6762

I would vote to follow the RFCs instead of voting based on something else.

That would mean (from my understanding):

1. example.org whenever needing a domain within documentation. (.org because of typo3.org, but could be any of the named from RFC). Which would follow the initial comment on this issue.
2. <custom domain name>.localhost or just localhost whenever referring to a local setup

[DanielSiepmann]

So I think the best recommendation is .test for a locally used domain. https://en.wikipedia.org/wiki/.test

The RFC https://datatracker.ietf.org/doc/html/rfc6761#section-6.2 is newer then https://datatracker.ietf.org/doc/html/rfc2606 from wikipedia and states:

However, since there is no central authority responsible for use of test names, users SHOULD be aware that these names are likely to yield different results on different networks.

Also the reference from Wikipedia also only states:

".test" is recommended for use in testing of current or new DNS related code. — ­https://datatracker.ietf.org/doc/html/rfc2606#section-2

Which isn't scope of our documentation.

I'd try to stick to best practices derived from the RFCs which work with a wide range of software. To my knowledge: All browsers support *.localhost to be resolved to the local IP. Containers are also locally on localhost, just encapsulated and should share their ports and resolve fine (but didn't work with them for a long time already). But I guess people tend to use another layer anyway, e.g. proxies like within ddev? So we can not make any wide range assumption on those setups anyway.

[gilbertsoft]

All browsers support *.localhost to be resolved to the local IP

It's the DNS resolver / OS doing this, not the browser.

example.local

Is a very bad choice because Apple devices have a special handling here regarding .local. DDEV also started with this TLD but we had to change it and are now using a registered domain ddev.site to avoid the problems with the TLD.

[alexander-nitsche]

Done.