golang.org/x/net/trace registration is hard to use with third-party HTTP muxers

[mic...@improbable.io]

I'd like to use the amazing golang.org/x/net/trace library. Howevever, my HTTP-serving binaries are using the Gorilla Mux for the request routing. 

Unfortunately, the trace package doesn't expose the http.HandleFunc as a public interface, instead registering private methods in the package's init() function to the http.DeafultServerMux.

The net/http/pprof package takaes a similar approach, registering default handlers, but it still maintains flexibility of exporting the relevant HandlerFunc allowing greater flexibility.

How can I contribute to make trace HTTP handlers more flexible in use?

Cheers,

Michal

Head of Infrastructure

Improbable

[Luuk van Dijk]

Can't you set the DefaultHandler from net/http as the NotFound handler in the GorillaMux handler http://www.gorillatoolkit.org/pkg/mux#Router ?

[Luuk van Dijk]

or you could register net/http.DefaultHandler as the handler for a couple of handpicked routes in the gorilla/mux.Router.

[Greg Roseberry]

Put your Gorilla router in http.DefaultServeMux.

router := mux.NewRouter()

http.Handle("/", router)

Then use http.DefaultServerMux (like http.ListenAndServe(":8000", nil)) and they should play well together. 

This is how the default serve function in frameworks like Goji usually work.  

[Michal Witkowski]

I'm not arguing that things can't be hacked together. I'm also not arguing against having an init register debug endpoints in DefaultServerMux, this is very useful for most users.

I just think that having to do dances with muxes is very ugly and brittle. IMHO, Go's biggest strength lays in the great composability enabled by third-party libraries adhering to types and interfaces defined in the standard libraries.

Fixing this is relatively eas:, moving the existing HandleFunc out. However, in the spirit of https://golang.org/doc/contribute.html#Design I wanted to know whether anyone else is working on this, or whether it is considered a good idea at all.

[Luuk van Dijk]

while i see your point i don't think the 'dance' with muxes is that ugly or brittle:  a mux is just a map of paths to handlers.  After a library puts its own handler  in such a map it is still perfectly accessible.   And composing muxes is just another form of composing.  E.g. I frequently put the net/http.FileServer as the NotFound handler in the gorilla mux.  gorilla handles all the dynamic endpoints and what it doesn't handle is then looked up as a static file from that handler. 

Actually, you could get the handler out by asking the standard mux once at program start by calling its Handler with a fake request and register that under whatever path you want.  I agree that that would be a tad klunky.

A (not very strong) argument against moving HandleFunc out is that that lets you to decide under which path to register it again.  It's very nice for organisations if standard facilities are found in standard places.  

But i don't see a really strong argument against exposing the trace handler either. 

/L

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Hihyzgci1EU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Symonds]

File a bug and assign it to me. I have a TODO to expose the handler so
you can invoke it however you want.

[mic...@improbable.io]

David,

Filed: https://github.com/golang/go/issues/12195

I hope that's the right place, since https://github.com/golang/net is just a mirror without ability to track Issues.

Thanks!

M

[j...@bountyapp.co]

David,

Although it isn't strictly required, I think changing the hrefs in the template to be relative would go a long way in making the proposed exposed handlers more useful. Is this request more appropriate for a separate issue/discussion?

Joe

[David Symonds]

On 22 August 2015 at 06:35, <j...@bountyapp.co> wrote:

> Although it isn't strictly required, I think changing the hrefs in the
> template to be relative would go a long way in making the proposed exposed
> handlers more useful. Is this request more appropriate for a separate
> issue/discussion?

They aren't already?

[Joseph Bernstein]

Maybe i'm misunderstanding, I just started looking at the net package. I think they are relative for the events handler but not the requests handler.

https://github.com/bountylabs/net/commit/6348c8d15dc07a9385c2adbe81ef4ec6516ac91c

[David Symonds]

Okay, that should be easy to fix upstream. I'll do that.