[Roy-Orbison]

Rather than having two independently-resolved default addresses, the http.ssl.address inherits the host from http.address.

Reason for This PR

When using conf of full, explicit address in http.address (e.g. [::]:80 for dual-stack) but only a port for http.ssl.address (e.g. :443), the SSL address to bind is implied by the config hierarchy but is currently not inherited, which is unintuitive. It results in bound addresses looking like this (from ss -plnt):

LISTEN 0      4096         0.0.0.0:443       0.0.0.0:*    users:(("rr",pid=67697,fd=14))
LISTEN 0      4096               *:80              *:*    users:(("rr",pid=67697,fd=13))

When last I looked, the config docs read:

    # Default: ":443"

but now contain an explicit host. This could be reverted for simplicity.

Description of Changes

Preprocess the SSL address directive to inherit the host part from the parent, but respect any explicit address in the SSL value, and retain the default IPv4-only of the parent (e.g. both directives are colon & port only). I didn't make any docs changes as they're contingent on interest in this change, and CHANGELOG.md seems to be only for released changes.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the MIT license.

PR Checklist

• All commits in this PR are signed (git commit -s).
• The reason for this PR is clearly provided (issue no. or explanation).
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this PR.
• Any user-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.

[rustatian]

Hey @Roy-Orbison 👋🏻
Thank you for the PR 👍🏻
It does not solve any problems, but adding not needed code, except of the un-untuitive statement, which I don't agree with.
In production, usage of the wildcard addresses, like 0.0.0.0 instead of binding to the specific IP is a dangerous practice.

[Roy-Orbison]

It solves double-specification, so config would be DRY. No one who specified something like

http:
  address: '[2001:db8:c0ff:ee:1:2:3:4]:80'
  ssl:
    address: ':443'

would reasonably expect the server to be listening on a single IPv6 for insecure connections (which browsers' won't even use by default, these days) but only on IPv4 0.0.0.0:443 for the real application, Roadrunner's current behaviour. You're asserting that it is intuitive that a dedicated, single-app server would bind to different addresses & address families, when the only difference in functionality between the two is TLS or not; I doubt many app authors would agree. A general web server with multiple virtual hosts might, but not a single app. How would one make use of Roadrunner's redirect: true feature if they're not listening in the same place?

The security of the wildcard address is irrelevant to this issue because the behaviour also exists when a specific IP is configured, and if the wildcard is insecure, why is it used by default, as above? Furthermore, [::] is the only way to get dual-stack with Roadrunner because it lacks support for multiple listen addresses. The implication here is you recommend not to use dual stack at all, which is pretty poor.