Skip to content

Add --https-bind for HTTPS-only connections on a different port #26263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
scaleoutsean opened this issue Apr 14, 2025 · 0 comments
Open

Add --https-bind for HTTPS-only connections on a different port #26263

scaleoutsean opened this issue Apr 14, 2025 · 0 comments
Labels

Comments

@scaleoutsean
Copy link

It's not a strong use case, but since I was asked to share it, I'll register it.

Use case:
If HTTPS port can be made available on a different port at the same time:

  • InfluxDB 3 clients can choose the port/protocol that suits their needs
  • No need to deal with the various burdens of workarounds such as reverse proxies to accommodate the "other" protocol
  • Less guesswork for developers and users. The fact that one is using the wrong protocol isn't difficult to spot, but it's harder and more annoying to do that from clients such as Grafana.

Proposal:

  • Allow both --http-bind and --https-bind for convenience and choice
  • I have no opinion on how --https-bind should behave if --tls-* args or ENV vars aren't available (ignore, generate self-signed, etc.)

Current behaviour:
As described in the documentation, client has to know what to use at given port - HTTP or HTTPS - and all clients must pick whatever is offered.
If HTTP is selected because not all clients can use HTTPS, that's one extreme. If HTTPS is selected for everyone's good, older (e.g. TLS v1.1) clients may not be able to access InfluxDB even when all they do is just make simple non-mission critical read-only queries.

Desired behaviour:
Clients can choose to connect without or with TLS encryption if the server offers both.

Alternatives considered:
Currently there's no alternative to using whichever protocol is in place (HTTP or HTTPS) cluster-wide, so I guess the only way is to stand up and maintain a separate reverse proxy which isn't insignificant (cost, performance, maintenance, etc.).

@hiltontj hiltontj added the v3 label Apr 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants