Also, can we get the original err from the p.copyResponse() somehow?

The panic obfuscates the original error with a generic http.ErrAbortHandler error.

Are you not using http.Server? The http.Server automatically handles ErrAbortHandler.

Also, #23643 which was included in Go 1.11 was supposed to even fix the case of not running under an http.Server.

So I'm really curious about your environment.

Do you have a minimal repro?

@bradfitz yes, we're using http.Server. The panic is handled and the program doesn't crash.

However, we use some HTTP middlewares that report all panics to Sentry and to our Logs. And now I'm curious what to do with this generic error.

Should we start filtering http.ErrAbortHandler out?
Can we get the original cause error somehow?

I don't know what your middleware wants to do, but here's the documentation for that panic value:

https://golang.org/pkg/net/http/#ErrAbortHandler

ErrAbortHandler is a sentinel panic value to abort a handler. While any panic from ServeHTTP aborts the response to the client, panicking with ErrAbortHandler also suppresses logging of a stack trace to the server's error log.

You can modify your middleware as appropriate.

There is no way to get the original cause. Usually it's because the client went away (closed browser tab, etc) and the proxy copy thus failed.

ErrAbortHandler is a sentinel panic value to abort a handler. While any panic from ServeHTTP aborts the response to the client, panicking with ErrAbortHandler also suppresses logging of a stack trace to the server's error log.

OK. I think it makes sense to suppress these errors in our middleware too. Thanks!