Show HN: Golang HTTP Clients/Servers and Alternative Networking
github.com
Show HN: Golang HTTP Clients/Servers and Alternative Networking
1–9 of 9 posts
Re: Show HN: Golang HTTP Clients/Servers and Alternative Networking
#2Re: Show HN: Golang HTTP Clients/Servers and Alternative Networking
#3Re: Show HN: Golang HTTP Clients/Servers and Alternative Networking
#4Does this offer any control at the TLS level? I have been looking for alternate TLS stacks for Go, and the only one I really found was uTLS: https://github.com/refraction-networking/utls
Re: Show HN: Golang HTTP Clients/Servers and Alternative Networking
#5Re: Show HN: Golang HTTP Clients/Servers and Alternative Networking
#6Does this offer any control at the TLS level? I have been looking for alternate TLS stacks for Go, and the only one I really found was uTLS: https://github.com/refraction-networking/utls
You can plug your own TCP stack in if you would like. The only thing you have to do is run the TCP handshake before you hand the net.Conn off to either the HTTP.RoundTripper or the net.Listener. The implementation would be very similar to what I did here.
Re: Show HN: Golang HTTP Clients/Servers and Alternative Networking
#7Earlier quoted context omitted.
You can plug your own TCP stack in if you would like. The only thing you have to do is run the TCP handshake before you hand the net.Conn off to either the HTTP.RoundTripper or the net.Listener. The implementation would be very similar to what I did here.
so no?
OpenZiti the project takes over protocol security for you by securing a network connection at the host or software level. So OpenZiti does not let you bring your own stack
The examples here show how to do what you are asking with the standard Go libraries. So it is a path you can replicate with your own stack choices.
Re: Show HN: Golang HTTP Clients/Servers and Alternative Networking
#8Problem with HTTPS is some browser functionality requires secure contexts.
However, in the broader context of browsers working with alternative networks: whether they work or not over HTTPS depends on the networking solution. With OpenZiti a tunneler working with the OS host's routing tables and DNS provider, the browser has no idea that OpenZiti exists. As long as DNS resolves and the x509 certificates pass SNI IP/DNS checking, the browser will not care.
OpenZiti also has "browzer" coming - which allows browsers to access HTTP APIs/web pages over OpenZiti networks seamlessly.
Re: Show HN: Golang HTTP Clients/Servers and Alternative Networking
#9Problem with HTTPS is some browser functionality requires secure contexts.
This post isn't about browsers. It is about developed GoLang HTTP clients and servers. However, in the broader context of browsers working with alternative networks: whether they work or not over HTTPS depends on the networking solution. With OpenZiti a tunneler working with the OS host's routing tables and DNS provider, the browser has no idea that OpenZiti exists. As long as DNS resolves and the x509 certificates p…