-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
expvar,net/http/pprof: creates conflict with "GET /" route #65723
Comments
I expect that similar problems will be caused by the many other places in the std lib where http.HandleFunc is invoked with the old syntax |
Change https://go.dev/cl/564435 mentions this issue: |
I guess it needs also to check whether the GODEBUG |
With the new routing style in go 1.22, declaring http.Handle("GET /", h) generates a conflict with route "/debug/vars" declared in the expvar package. You get an error such as: panic: pattern "GET /" (registered at ...) conflicts with pattern "/debug/vars" (registered at ...expvar.go:384): GET / matches fewer methods than /debug/vars, but has a more general path pattern This patch prevents that error. Adding GET is correct because no other method makes sense with /debug/vars. We preserve the traditional behaviour when GODEBUG=httpmuxgo121=1 is specified.
With the new routing style in go 1.22, declaring http.Handle("GET /", h) generates a conflict with route "/debug/vars" declared in the expvar package. You get an error such as: panic: pattern "GET /" (registered at ...) conflicts with pattern "/debug/vars" (registered at ...expvar.go:384): GET / matches fewer methods than /debug/vars, but has a more general path pattern This patch prevents that error. Adding GET is correct because no other method makes sense with /debug/vars. We preserve the traditional behaviour when GODEBUG=httpmuxgo121=1 is specified.
Indeed, this is needed, otherwise specifying GODEBUG (I closed the previous PR by mistake, so I had to open a new one. Newbie mistake!) |
Change https://go.dev/cl/564735 mentions this issue: |
@bradfitz per owners |
@jba FYI |
|
@xpmatteo, would you like to handle |
I will do it; should I open a separate PR? |
Yes please. |
With the new routing style in go 1.22, declaring http.Handle("GET /", h) generates a conflict with route "/debug/vars" declared in the expvar package. You get an error such as: panic: pattern "GET /" (registered at ...) conflicts with pattern "/debug/vars" (registered at ...expvar.go:384): GET / matches fewer methods than /debug/vars, but has a more general path pattern This patch prevents that error. Adding GET is correct because no other method makes sense with /debug/vars. However, a tool using any other methods will break. We preserve the traditional behaviour when GODEBUG=httpmuxgo121=1 is specified. Fixes golang#65723
With the new routing style in go 1.22, declaring http.Handle("GET /", h) generates a conflict with route "/debug/pprof/" and the others declared in the net/http/pprof package. You get an error such as: panic: pattern "GET /" (registered at .../pprof.go:94): GET / matches fewer methods than /debug/pprof/, but has a more general path pattern [recovered] panic: pattern "GET /" (registered at ...:17) conflicts with pattern "/debug/pprof/" (registered at .../pprof.go:94): This patch prevents that error. Adding GET is correct because no other method makes sense with the /debug/pprof routes. However, a tool using any method other than GET will break. We preserve the traditional behaviour when GODEBUG=httpmuxgo121=1 is specified. This is related to issue golang#65723
With the new routing style in go 1.22, declaring http.Handle("GET /", h) generates a conflict with route "/debug/pprof/" and the others declared in the net/http/pprof package. You get an error such as: panic: pattern "GET /" (registered at .../pprof.go:94): GET / matches fewer methods than /debug/pprof/, but has a more general path pattern [recovered] panic: pattern "GET /" (registered at ...:17) conflicts with pattern "/debug/pprof/" (registered at .../pprof.go:94): This patch prevents that error. Adding GET is correct because no other method makes sense with the /debug/pprof routes. However, a tool using any method other than GET will break. We preserve the traditional behaviour when GODEBUG=httpmuxgo121=1 is specified. This is related to issue golang#65723
Change https://go.dev/cl/565176 mentions this issue: |
With the new routing style in go 1.22, declaring http.Handle("GET /", h) generates a conflict with route "/debug/pprof/" and the others declared in the net/http/pprof package. You get an error such as: panic: pattern "GET /" (registered at .../pprof.go:94): GET / matches fewer methods than /debug/pprof/, but has a more general path pattern [recovered] This patch prevents that error. Adding GET is correct because no other method makes sense with the /debug/pprof routes. However, a tool using any method other than GET will break. We preserve the traditional behaviour when GODEBUG=httpmuxgo121=1 is specified. Updates golang#65723
With the new routing style in go 1.22, declaring http.Handle("GET /", h) generates a conflict with route "/debug/pprof/" and the others declared in the net/http/pprof package. You get an error such as: panic: pattern "GET /" (registered at .../pprof.go:94): GET / matches fewer methods than /debug/pprof/, but has a more general path pattern [recovered] This patch prevents that error. Adding GET is correct because no other method makes sense with the /debug/pprof routes. However, a tool using any method other than GET will break. We preserve the traditional behaviour when GODEBUG=httpmuxgo121=1 is specified. Updates golang#65723
With the new routing style in go 1.22, declaring http.Handle("GET /", h) generates a conflict with route "/debug/vars" declared in the expvar package. You get an error such as: panic: pattern "GET /" (registered at ...) conflicts with pattern "/debug/vars" (registered at ...expvar.go:384): GET / matches fewer methods than /debug/vars, but has a more general path pattern This patch prevents that error. Adding GET is correct because no other method makes sense with /debug/vars. However, a tool using any other methods will break. We preserve the traditional behaviour when GODEBUG=httpmuxgo121=1 is specified. Fixes golang#65723
With the new routing style in go 1.22, declaring http.Handle("GET /", h) generates a conflict with route "/debug/vars" declared in the expvar package. You get an error such as: panic: pattern "GET /" (registered at ...) conflicts with pattern "/debug/vars" (registered at ...expvar.go:384): GET / matches fewer methods than /debug/vars, but has a more general path pattern This patch prevents that error. Adding GET is correct because no other method makes sense with /debug/vars. However, a tool using any other methods will break. We preserve the traditional behaviour when GODEBUG=httpmuxgo121=1 is specified. Fixes golang#65723
With the new routing style in go 1.22, declaring http.Handle("GET /", h) generates a conflict with route "/debug/pprof/" and the others declared in the net/http/pprof package. You get an error such as: panic: pattern "GET /" (registered at .../pprof.go:94): GET / matches fewer methods than /debug/pprof/, but has a more general path pattern This patch prevents that error. Adding GET is correct because no other method makes sense with the /debug/pprof routes. However, a tool using any method other than GET will break. We preserve the traditional behaviour when GODEBUG=httpmuxgo121=1 is specified. Updates #65723 Change-Id: I49c21f5f3e802ad7538062d824354b2e4d8a800e GitHub-Last-Rev: 35e4012 GitHub-Pull-Request: #65791 Reviewed-on: https://go-review.googlesource.com/c/go/+/565176 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
FYI: This change broke some applications grafana/pyroscope-go#119 |
You can also use |
Yeah, the problem is that i do not own the app. It is a library. We're fixing the library. |
Go version
1.22.0
Output of
go env
in your module/workspace:What did you do?
What did you see happen?
What did you expect to see?
No error.
It can be fixed with this patch
The text was updated successfully, but these errors were encountered: