When a web module is set to listen over SSL, "http://" addresses should probably serve redirects to the "https://" equivalent, instead of a blank page.
When a web module is set to listen over SSL, "http://" addresses should probably serve redirects to the "https://" equivalent, instead of a blank page.
##
<bountysource-plugin>
---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/216075-http-should-redirect-to-https-when-applicable?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).
</bountysource-plugin>
<!-- github-sync-id:13132641 -->
Uhm, you aren't running znc as root, correct? So your znc isn't listening on port 80 nor port 443, right? If yes, then the answer is:
http and https on the same port is... un-good?
Uhm, you aren't running znc as root, correct? So your znc isn't listening on port 80 nor port 443, right? If yes, then the answer is:
http and https on the same port is... un-good?
<!-- github-comment-id:16329806 -->
Apache, nginx, & probably others have a way of serving a redirect from http to https on the same port. I don't know the details, but I assumed it wasn't too big of a hack.
Apache, nginx, & probably others have a way of serving a redirect from http to https on the same port. I don't know the details, but I assumed it wasn't too big of a hack.
<!-- github-comment-id:16329929 -->
A quick check of nginx' source code suggests: Whoa. No clue what they are doing. They use some internal 4xx status code (forgot which one) for this, but no idea how it is generated.
A quick check of nginx' source code suggests: Whoa. No clue what they are doing. They use some internal 4xx status code (forgot which one) for this, but no idea how it is generated.
<!-- github-comment-id:16350922 -->
Hmm, yeah, 497 (NGX_HTTP_TO_HTTPS).
At some level it's probably just check after receiving a bogus SSL hello to see if the client actually sent "GET ...".
Hmm, yeah, 497 (NGX_HTTP_TO_HTTPS).
At some level it's probably just check after receiving a bogus SSL hello to see if the client actually sent "GET ...".
<!-- github-comment-id:16354190 -->
This feature is useful. I hope developers could support it. Or let me have a try. But it seems that needs some changes to [Csocket](https://github.com/jimloco/Csocket).
https://github.com/nginx/nginx/blob/f72bcf8/src/http/ngx_http_request.c#L704
<!-- github-comment-id:285856116 -->
@ahammond This issue is about ZNC being able to receive an unencrypted request on an encrypted listen port and understand it enough to respond with a redirect that tells the client to reconnect to the same port using encryption.
@ahammond This issue is about ZNC being able to receive an unencrypted request on an encrypted listen port and understand it enough to respond with a redirect that tells the client to reconnect to the same port using encryption.
<!-- github-comment-id:412714279 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
When a web module is set to listen over SSL, "http://" addresses should probably serve redirects to the "https://" equivalent, instead of a blank page.
--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/216075-http-should-redirect-to-https-when-applicable?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).Uhm, you aren't running znc as root, correct? So your znc isn't listening on port 80 nor port 443, right? If yes, then the answer is:
http and https on the same port is... un-good?
Apache, nginx, & probably others have a way of serving a redirect from http to https on the same port. I don't know the details, but I assumed it wasn't too big of a hack.
A quick check of nginx' source code suggests: Whoa. No clue what they are doing. They use some internal 4xx status code (forgot which one) for this, but no idea how it is generated.
Hmm, yeah, 497 (NGX_HTTP_TO_HTTPS).
At some level it's probably just check after receiving a bogus SSL hello to see if the client actually sent "GET ...".
This feature is useful. I hope developers could support it. Or let me have a try. But it seems that needs some changes to Csocket.
https://github.com/nginx/nginx/blob/f72bcf8/src/http/ngx_http_request.c#L704
Related? https://superuser.com/questions/710253/allow-non-root-process-to-bind-to-port-80-and-443
@ahammond This issue is about ZNC being able to receive an unencrypted request on an encrypted listen port and understand it enough to respond with a redirect that tells the client to reconnect to the same port using encryption.