Setting ReadHeaderTimeout in your example code works for me. Does that solve it for you too?

My interpretation of the http.Server settings here is that once the server sees the first few bytes of the request, instead of being an "idle" connection subject to the "IdleTimeout" setting, the connection instead is considered active and subject to the "ReadHeaderTimeout" setting.

Yes, ReadHeaderTimeout works, but not everyone sets it.
I found another thing with the same server code, but the client sends only part of the data of a request, will also leak:

// client.go
package main

import (
	"log"
	"net"
	"time"
)

func main() {
	go func() {
		for i := 1; true; i++ {
			// Keep printing alive until the conn is closed and the process exit
			time.Sleep(time.Second)
			log.Printf("alive %vs", i)
		}
	}()

	conn, err := net.Dial("tcp", "localhost:8080")
	if err != nil {
		panic(err)
	}

	reqData := []byte("POST /echo HTTP/1.1\r\nHost: localhost:8080\r\nContent-Length: 5\r\nAccept-Encoding: gzip\r\n\r\nhello")
	// step 1: Send part of the data of a request
	_, err = conn.Write(reqData[:4])
	if err != nil {
		panic(err)
	}

	// step 2: Recv the first response
	// The server will not close the conn and will block here
	resData := make([]byte, 1024)
	n, err := conn.Read(resData)
	if err != nil {
		panic(err)
	}
	log.Printf("resData: \n-----\n%v\n-----\nerror: %v", string(resData[:n]), err)
}

ReadHeaderTimeout also works for this.

For these two client examples, both need users to set Server.ReadHeaderTimeout, but many people don't set it.

Slow connection attack, the device of the client power off, wifi changed, entering an elevator may cause that the client will never send TCP.FIN to the server, then the conn will never be closed and the goroutine serving the conn will never exit.

It seems like the famous frameworks based on net/http such as gin, use the default configuration as their default configuration:
https://github.com/gin-gonic/gin/blob/master/gin.go#L378

Many people use net/http and gin's default configuration, then, many projects may have this issue.

As a default configuration, I think it should not leave this side effect.

I think if ReadHeaderTimeout is zero, use someDefaultTimeout may be better.

Maybe golang itself should leave it to users to set the right configuration, but some frameworks should handle their default configuration.
So I'll close this but open some issues to other frameworks.

Thanks for your time!