Ability to determine current path/path template of match in handler

[nmiyake]

If a handler matches on a route that does not have a path template defined, it is currently not possible to look up the actual path that matched. It would be ideal if there was a way for GetPathTemplate to have an option to check its ancestors for the first defined template in a case where none is defined on the current route.

Example:

func TestHandlerPathTemplate(t *testing.T) {
	router := mux.NewRouter().StrictSlash(true)
	products := router.PathPrefix("/{products}").Subrouter()

	products.Methods("GET").Handler(http.HandlerFunc(func(rw http.ResponseWriter, req *http.Request) {
		fmt.Println(mux.CurrentRoute(req).GetPathTemplate())
		fmt.Println(mux.Vars(req))
	}))

	server := httptest.NewServer(router)
	defer server.Close()

	http.Get(server.URL + "/myProduct")
}

Current output:

 mux: route doesn't have a path
map[products:myProduct]

Expected:
Some way to be able to get "/{products}" as the path template, either by having a version of GetPathTemplate() that returns the first defined template of a route's ancestors or by exposing a way to access the parent of a route.

[nmiyake]

@kisielk @elithrar any thoughts on this? Not urgent since I'm able to work around this at the handler level (I use Walk to register a handler that knows its own match path based on the ancestors built up in Walk), but I do think that, from an API standpoint, it'd be nice if mux.Vars had an equivalent mux.Path/mux.Template (or something similar) where you could determine the path/path template that was used for a match. Currently, it's not possible to do this cleanly if the matched route itself doesn't have a regexp.

[elithrar]

I'm open to this. We should profile the performance before/after if we are stuffing more into mux.Vars though.

[kisielk]

I agree with @elithrar

[stale]

This issue has been automatically marked as stale because it hasn't seen a recent update. It'll be automatically closed in a few days.

[rbren]

Has this been implemented?

[matheuscscp]

Has this been implemented?

I wanna know that too.

[elithrar]

No, this was not implemented. PRs are accepted, noting the performance concerns above.

[fharding1]

It looks like this may have been fixed in 758eb64 which improved subroute propagation. Running the posted example now shows:

/{products} <nil>
map[products:myProduct]

Here is my bisect log:

➜  mux git:(3d80bc8) ✗ git bisect log 
git bisect start '--term-new=fixed' '--term-old=unfixed'
# fixed: [4de8a5a4d283677c69afa1a86a044c8451633a18] fix headers regexp test (#536)
git bisect fixed 4de8a5a4d283677c69afa1a86a044c8451633a18
# unfixed: [bdd5a5a1b0b489d297b73eb62b5f6328df198bfc] Fix WriteHeader in TestA301ResponseWriter. (#301)
git bisect unfixed bdd5a5a1b0b489d297b73eb62b5f6328df198bfc
# unfixed: [962c5bed0721b50f2ba42684e9600dfde174770f] Add 1.11 to build in travis (#398)
git bisect unfixed 962c5bed0721b50f2ba42684e9600dfde174770f
# fixed: [ed099d42384823742bba0bf9a72b53b55c9e2e38] host:port matching does not require a :port to be specified.
git bisect fixed ed099d42384823742bba0bf9a72b53b55c9e2e38
# fixed: [6137e193cdcba2725f16de84eaf0db2b769d9668] remove redundant code that remove support gorilla/context (#427)
git bisect fixed 6137e193cdcba2725f16de84eaf0db2b769d9668
# unfixed: [521ea7b17d02faf8d3afea6737573942ceac59c5] Use constant for 301 status code in regexp.go (#412)
git bisect unfixed 521ea7b17d02faf8d3afea6737573942ceac59c5
# fixed: [758eb64354aa27cda6c1b026822c788cc755f06f] Improve subroute configuration propagation #422
git bisect fixed 758eb64354aa27cda6c1b026822c788cc755f06f
# unfixed: [3d80bc801bb034e17cae38591335b3b1110f1c47] Use subtests in mux_test.go (#415)
git bisect unfixed 3d80bc801bb034e17cae38591335b3b1110f1c47
# first fixed commit: [758eb64354aa27cda6c1b026822c788cc755f06f] Improve subroute configuration propagation #422