I can't think of a way to solve this and keep urls such as http://musicbrainz.org/tag/rock/artist.

Perhaps we should be blocking tags with '/' in them.

URI escape "rock/artist" into "rock%2Fartist" (don't worry about 'breaking" "tag/rock/artist", because it was never right in the first place).

URI escape doesn't seem to help. http://beta.musicbrainz.org/tag/hip-hop%2Frap just loads the tags for "hip-hop".

URI-escaping doesn't help, at present, because Catalyst's argument capturing doesn't know the difference between / and %2F, as far as I know. Certainly at present it doesn't work, there may be an incantation that does make it differentiate.

Agreed to fix within 12 months by http://scheduling.ocharles.org.uk/results and http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-06/2012-06-11.html

I think the fix for this is to disallow / in tags (and editor names), and probably bulk-convert them to something else. We could be Mac-like and make ':' display as a /, and thereby disallow colons instead, if we really want to keep slashes.

I vote for keeping the slashes. There are several reasons to allow '/' as a valid character - for example many people that use it for genres/styles in a variety of cases.

If I try and access a tag from my profile page with a slash I simply get my profile page. The only way i've found around this is to manually double-escape the '/' by using %252F instead of %2F. Perhaps just make that change to the links in MBz then you don't have to mess with URIs?

Is this a new bug (regression) ?
IIRC, this old tag of mine used to work but maybe I'm wrong fix 秋元裕子 http://musicbrainz.org/edit/14273514 (incomplet :/ ends with slash leads to different page as error).

After a bit of local testing I can confirm that replacing '/' by '%252F' does work, though no number of 'url_escape' in templates seems to do the same. Also works for editors.

Most of this is pretty easy to fix – wrapping replace(<whatever>, '/', '%252F') in templates, or <whatever> ~= s/\//%252F/rg in perl. There's some lurking issue about how catalyst urlencodes and urldecodes things as it forwards and redirects that means logins sometimes don't work or redirect to the wrong place; I may put up a codereview only for the first and open a new bug for the second.

Ian, thanks for this work-around ! I'll try to remember to add this 25 stuff...

This is in review at http://codereview.musicbrainz.org/r/2062/ and available for testing on http://test.musicbrainz.org/