I get what you're saying. I did something similar, but modifying all those
structures places you at risk of changing the entire default specified
behaviour of the ListenAndServeTLS because you now not only introduced the
limitConnections integer, but you in fact brought in other
I managed to expand ListenAndServeTLS and then apply LimitedListener.
My code and process are posted at
https://pocketgophers.com/limit-https-listener/
tcpKeepAliveListener ended up being the only code that was copied but not
specialized. It would have been nice if it were exported from the
I tried just what you mentioned. Unfortunately even my interim solution
when it is outside of the net.http package and within mine, there are many
services that are not exported meaning I can't use them at all and the
variables themselves are inaccessible.
I tried copying pasting some
I perused your blog entry you mentioned. It's very interesting and will
come in handy in the future. Thank you.
I can appreciate your point of view about accepting the fact that currently
listeners are not part of the Server and just proceed to produce code and
get it done ASAP. My
The issue here in essence is that an http.Server doesn't store a
new.Listener to expose, it only operates on one provided to the Serve
method. Without changing the api, there's no way to expose a listener in an
http.Server in a way that doesn't interfere with the other methods.
However, I
Your research revealed the essential lines from ListenAndServeTLS that
basically say:
1. create a tls listener
2. have the server serve using that listener
The LimitListener example follows this same pattern, just with net.Listener
instead of a tls.Listener. A careful reading reveals that
Another question: Why wasn't tlsListener placed as part of the Server structure?
I think it makes sense to place it there since it is the server that creates
and uses it.
It also makes sense to expose it to tweak it as some might more control over it
and in this case the constraining the
