net/http: panic when a nil HandlerFunc is passed to http.HandleFunc

[snowdusk]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.9.2

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

amd64 linux

What did you do?

package main

import "net/http"

func main() {
    http.HandleFunc("/", nil)
    http.ListenAndServe(":8080", nil)
}

What did you expect to see?

when I go run this file, the nil error appears not in compilation time but in run time. The reason is that http.Handler(http.HandlerFunc(nil)) == nil is false. BUT use reflect we can know the value of http.Handler(http.HandlerFunc(nil)) is nil, so the error should be stopped in compilation time by fix Handle function.

What did you see instead?

[davecheney]

Please finish filling in the issue template, specifically what did you see when you ran your example. What would be the ideal resolution to this bug for you?

…

On 7 March 2018 at 23:22, wangsong93 ***@***.***> wrote: Please answer these questions before submitting your issue. Thanks! What version of Go are you using (go version)? 1.9.2 Does this issue reproduce with the latest release? yes What operating system and processor architecture are you using (go env)? amd64 linux What did you do? package main import "net/http" func main() { http.HandleFunc("/", nil) http.ListenAndServe(":8080", nil) } What did you expect to see? when I go run this file, the nil error appears not in compilation time but in run time. The reason is that http.Handler(http.HandlerFunc(nil)) == nil is false. BUT use reflect we can know the value of http.Handler(http.HandlerFunc(nil)) is nil, so the error should be stopped in compilation time by fix Handle function. What did you see instead? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24297>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA3FK20x0q5p1QSu-o8vnaJZTIaQ7ks5tb9ECgaJpZM4SgWre> .

[namusyaka]

I guess he would like to say that it is a matter of panic occurring after the mux actually received the request. It will be something like the following error:

http: panic serving [::1]:51880: runtime error: invalid memory address or nil pointer dereference

And it is possible to generate a more descriptive panic by actually checking whether it is nil at the timing when HandleFunc is called without using reflect. It would be something like:

diff --git a/src/net/http/server.go b/src/net/http/server.go
index a7ba753bf5..04a0444140 100644
--- a/src/net/http/server.go
+++ b/src/net/http/server.go
@@ -2358,6 +2358,9 @@ func (mux *ServeMux) Handle(pattern string, handler Handler) {

 // HandleFunc registers the handler function for the given pattern.
 func (mux *ServeMux) HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
+       if handler == nil {
+               panic("net/http: handler must not be nil")
+       }
        mux.Handle(pattern, HandlerFunc(handler))
 }

/cc @bradfitz @tombergan

[andybons]

We won’t be able to catch this at compile time. @namusyaka’s fix seems reasonable unless I’m missing something.

[snowdusk]

I mean how to reproduce the panic in following code even if the 2nd parameter is nil

func (mux *ServeMux) Handle(pattern string, handler Handler) {
	mux.mu.Lock()
	defer mux.mu.Unlock()

	if pattern == "" {
		panic("http: invalid pattern " + pattern)
	}
        // if reflect.ValueOf(handler).IsNil() { // this can be a solution
	if handler == nil {
		panic("http: nil handler")
	}
	if mux.m[pattern].explicit {
		panic("http: multiple registrations for " + pattern)
	}

[namusyaka]

I'm going to send a CL about this problem in a few days.

[namusyaka]

@wangsong93 I don't think it is a solution about the issue. Since it is called on every request, it should not be an essential solution.
In order to solve the issue you reported, it is enough to check the second argument when http.HandleFunc is called.

[snowdusk]

@namusyaka yes, your solution is better and I agree. My solution is just used to verify my idea. Nil parameters should be stopped as earlier as possible.

[gopherbot]

Change https://golang.org/cl/99575 mentions this issue: net/http: improved to detect nil Handler when calling (*ServeMux)HandleFunc