Skip to content
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

Feature request: mux implementation in httptest allowing modification of handler #29838

Closed
geekodour opened this issue Jan 19, 2019 · 3 comments

Comments

@geekodour
Copy link

commented Jan 19, 2019

Currently the mux.Handle implementation in net/http panics if a handler already exists for pattern.

For a test I was writing, It would be nice if I could change the handler for a pattern.

If this is a feature that can be added, I'll be happy to send a PR.

https://godoc.org/net/http#ServeMux.Handle

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jan 22, 2019

Your issue title says "in httptest", but you're proposing modifying net/http, right? Not httptest?

Can't you just write two small tests rather than one big test?

Or use subtests? Or re-create the ServeMux?

Or use an http.Handler implementation that does the switcheroo muxing itself?

@geekodour

This comment has been minimized.

Copy link
Author

commented Jan 23, 2019

@bradfitz I managed to do this with recreating the ServeMux for each test.

Your issue title says "in httptest", but you're proposing modifying net/http, right? Not httptest?

I thought, for net/http's mux, it is desirable that It does panic on duplicate pattern.

So, a separate mux implementation in net/http/httptest which allows changing of handlers for the same pattern.

Otherwise,

We can add another method such as mux.HandleNoPanic to net/http which does not panic on duplicate pattern.

But I don't know if it was necessary, I cannot think of any other usecase other than the original issue I listed above for the test which I was able to solve by recreating the ServeMux

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jan 23, 2019

Okay, let's close this then. If other needs emerge later we can discuss then.

@bradfitz bradfitz closed this Jan 23, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.