You can easily do this today by making your own net.Listener.

ln, err := net.Listen("tcp", ":80")
if err != nil {
  // ...
}

The only thing ListenAndServe adds beyond this is TCP keepalive, but that's also easy to do yourself.

That's true. That's what I've done up until now, though I was hoping to avoid redoing the TCP keepalive code, since it's already there in net/http, unexported.

I agree that it's a little bit annoying that "ListenAndServe" isn't directly the same as "Serve" with a net.Listener. I think this should definitely be added to the docs to inform that ListenAndServe != Listen + Serve. However, I think that having a special http.Listen, which would be identical to net.Listen except for keep-alive, would be too much, and will just add to the confusion, without really solving that much.

Not only does "Listen" by itself not say anything obvious about keep-alive, but keep-alive is in no way HTTP specific. You should do this in almost all your Accept loops. Instead, you could request for a net.ListenWithKeepAlive, but I'm not sure that request would gain much traction.

I would rather fix this with documentation (about ListenAndServe doing the keep-alive stuff), and ideally not much documentation. I don't want to add more API surface.

The net and net/http packages are large enough. The small percentage of people needing custom listeners can code up exactly what they want. Once we added some sort of keep-alive-listener type, then the question would be how to configure it. Best to just let people write the thing they want. It's not much code.

/cc @adg since it's a proposal

Agree with @bradfitz that we should just document the status quo.

No problem. Thank's for the response.