Skip to content
  • David Fifield's avatar
    Use ListenAndServe{TLS} rather than separate Listen and Serve. · 19b317e7
    David Fifield authored
    This is a port of commit cea86c937dc278ba6b2100c238b1d5206bbae2f0 from
    meek. Its purpose is to remove the need to copy-paste parts of
    net/http.Server.ListenAndServeTLS. Here is a copy of the commit message
    from meek:
    
        The net/http package provides ListenAndServe and ListenAndServeTLS
        functions, but it doesn't provide a way to set up a listener without
        also entering an infinite serve loop. This matters for
        ListenAndServeTLS, which sets up a lot of magic behind the scenes for
        TLS and HTTP/2 support. Formerly, we had copy-pasted code from
        ListenAndServeTLS, but that code has only gotten more complicated in
        upstream net/http.
    
        The price we pay for this is that it's no longer possible for a server
        bindaddr to ask to listen on port 0 (i.e., a random ephemeral port).
        That's because we never get a change to find out what the listening
        address is, before entering the serve loop.
    
        What we gain is HTTP/2 support; formerly our copy-pasted code had the
        side effect of disabling HTTP/2, because it was copied from an older
        version and did things like
                config.NextProtos = []string{"http/1.1"}
    
        The new code calls http2.ConfigureServer first, but that's not what's
        providing HTTP/2 support. HTTP/2 support happens by default. The reason
        we call http2.ConfigureServer is because we need to set
        TLSConfig.GetCertificate, and http2.ConfigureServer is a convenient way
        to initialize TLSConfig in a way that is guaranteed to work with HTTP/2.
    19b317e7