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 also don't like that it's not completely trivial to create your own listener identical to that used by the http.Server. The basic http server isn't so bad, but does make use of a small tcpKeepAliveListener wrapper. The https method is a little more complicated, since it may modify the tls.Config. Maybe we could propose helper functions or methods for Listen and ListenTLS, which return a net.Listener? (I feel like there were related issues files, but I'm not finding them at the moment) On Wednesday, August 3, 2016 at 8:03:03 AM UTC-4, David Marceau wrote: > > I can understand at first glance we may perceive ListenAndServeTLS as a > convenience helper, but if enough people to copy and paste its contents to > modify it, then the sublety is > the function is actually assumed to be part of a Foundation/Framework that > people build on top of. It is under the golang/net after all. It was meant > simply to be used and extended, NOT rewritten. > > A framework usually has a manner in which to access all its > class/duck-type's attributes and services. In this case the package net > has a number of duck-types, Client, Server. > Most of the Server's attributes are accessible, but stunningly the > listener itself does not belong to the Server duck-type when I believe it > should. Otherwise the other suggestion would be to make it available by > making it a return variable if other framework devs feel it shouldn't be > part of the Server duck-type. For those that don't want to tweak the > listener, they can simply use the _ standard to ignore that return variable. > > That said, I believe the listener is core and should be available from > this one service. I'm sure there are other developers that rely on > ListenAndServeTLS and implicit understand exactly what it does. I'm not > asking to change anything in their understanding about its behaviour. I > asking the golang team to change something to in its characteristics which > fundamentally belongs to the Server duck-type which extends its original > meaning to something developers assume to be there in the first place. I'm > surprised > > LimitListener(srv.tlsListener, connectionCount) is not part of the Server > duck-type's api. It makes sense to be there. I'm stunned it's not there. > That's why I came to the forum to ask why it wasn't there the first place. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
