Skip to content
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

Optional fallback support for missing or unknown SNI hostname #6

Open
spacesynth opened this issue Apr 24, 2024 · 0 comments
Open

Optional fallback support for missing or unknown SNI hostname #6

spacesynth opened this issue Apr 24, 2024 · 0 comments

Comments

@spacesynth
Copy link

spacesynth commented Apr 24, 2024

Great server! Very fast and stable for me. There is some improvement possible:

routes:
- fallback:
  backend:
    address: "127.0.0.1:3443"
- domains:
  - "example.net"
  backend:
    address: "1.2.3.4:443"

Clients or bots not sending SNI hostname or an unknown one in message are a completely normal thing. This should not be an error. Instead the loglevel should raise only (Debug) on clients with no SNI field or hostname. So we can handle them better.

Imagine
(Debug) Client sent empty or unknown SNI hostname, taking the fallback route

If an optional fallback server was defined on a custom IP:PORT by the user, we send all requests with empty or unknown SNI hostname there.

What do you think?

@spacesynth spacesynth reopened this Apr 29, 2024
atenart added a commit that referenced this issue Dec 12, 2024
This is similar to what we do in the HTTP parser, if no hostname is
there we can't do much but it's not really an error.

This was suggested in #6.

Signed-off-by: Antoine Tenart <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant