proposal: net/http: add Listen and ListenTLS to http.Server

[kaleworsley]

I'd like to extract part of ListenAndServe and ListenAndServeTLS into separate
Listen and ListenTLS methods, respectively. This would make it possible to call
syscall.Setuid after listening on a privileged port.

For example:

package main

import (
    "fmt"
    "net/http"
    "syscall"
)

func handle(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello! I'm UID 501.")
}

func main() {
    s := http.Server{
        Addr:    ":80",
        Handler: http.HandlerFunc(handle),
    }

    ln, err := s.Listen()

    if err != nil {
        panic(err)
    }

    syscall.Setuid(501)

    s.Serve(ln)
}

I have written a patch, but wanted to check if it's a reasonable idea before submitting it.

[cespare]

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.

[kaleworsley]

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.

[minux]

Please note that at least on Linux, syscall.Setuid always fails with EOPNOTSUPP. I think what you want is possible without the new API, you just need to create your own listener and call the Serve method.

[kennylevinsen]

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.

[bradfitz]

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

[adg]

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

[kaleworsley]

No problem. Thank's for the response.