Closed systemcrash closed 1 year ago
Understood!
The rationale behind this parameter is when using a reverse-proxy/load-balancer, the real exposed port has nothing to do with the bind
ed port: most likely you'll have nginx serving mydomains.example.net
with a TLS termination, on port 443 and happyDomain on the same machine, listening on port 8081, without TLS. Links in mails need to reflect what is setup outside the scope of happyDomain.
To solve this, we should:
url.Scheme
is given after parsing the value (if not defined, most likely the parameter is not filled correctly).I just add the repository used for the documentation to our Github organization: https://github.com/happyDomain/help (from https://git.happydomain.org/help).
Tried mashing this into my docker compose.
First wrote:
happyDomain_externalurl=domain-name
Problem: receiving mail host assumed the domain-name was a path (on its infra), and not a hostname. Opened URL was:
https://mail-host/domain-name/.....
Then tried:
happyDomain_externalurl=http://domain-name
Problem: page not found, because correct port was not supplied
Then tried:
happyDomain_externalurl=http://domain-name:8081/
Problem: page not found, because root path became
...//
Finally figured out that it needs to be:
happyDomain_externalurl=http://domain-name:8081
Please document these defaults, and what 'format' they are expected to be in, or perhaps add a few guard-rails so that HD auto-adds :8081 and http:// if absent.
My experience with docker and web services is that e.g. :8081 would be automatically added, because the param
bind
exists.Also would be an idea to expose the docu git repo here on github.