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

[philcluff]

Say I have an API with a URL structure as follows: http://example.com/library/$BOOKID/chapters

If someone hits the URL http://example.com/library//chapters (Fails to provide a bookID), the client will receive a 301 to a location which doesn't exist (301 -> follow -> 404)

In my opinion, this behaviour should be optional, the problem is of course that path.Clean() is called, and (As per documentation) // 1. Replace multiple slashes with a single slash. is performed.

Most my reasoning for not wanting this behaviour is based on me not wanting my routing library to redirect my clients when I'm not explicitly asking it to.

What are others thoughts on this?

Cheers,

[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.

[elithrar]

This should be fixed in #154.

[philcluff]

Great, thanks!