cleanPath() causing a change in the URL should not necessarily cause a redirect about mux

[elithrar]

This should be fixed in #154.

[bundah]

I agree with your reasoning. Granted, the client is hitting the endpoint incorrectly. However path.Clean doesn't just trim trailing slashes (as code comments say https://github.com/gorilla/mux/blob/master/mux.go#L348), it trims all extra slashes and in some cases dots too... because it is meant more for filesystem pathing IMO. Perhaps a better approach ( don't know the exact rationale for the current implementation) is logic surrounding StrictSlash and https://golang.org/pkg/strings/#TrimRight with "/" as the cutset...

[kisielk]

The cleanPath behaviour is identical to that of the net/http mux.

[kisielk]

and actually the redirect behaviour is basically the same as well... so I'm not really inclined to change the way it is working right now

[dylanmei]

Since I've started using Traefik -- which enlists gorilla/mux in its routing layer -- I've discovered two backend apps that no longer function as designed.

• thumbor/thumbor
• Capgemini/mesos-ui

They both use urls with their proxy data in the path, as opposed to a query-string. For example:

http://my-app/proxy/http://another-app

While I don't personally agree with their design decisions, these apps and probably many more are unusable due to the path cleaning / redirect.

[elithrar]

Related: #142

[elithrar]

One (quick and dirty) option would be to provide a .NoClean() method on Route to skip the path cleaning logic and leave that up to the package user.

The risk there is that it's a sharp edge that—if you don't carefully write your own path-cleaning logic—you could break your application in other ways.

[philcluff]

Great, thanks!