Add implicit optional format param to routes

[Ryman]

BREAKING CHANGE

This will break code that tries to handle routes such as: '/foo/:bar.:baz'

You can now handle this with: '/foo/:bar'

When this route matches '/foo/cats.gif' then request.param("format") will be ".gif"

Fixed #90.

cc: @pzol @cburgdorf @simonpersson

Currently we're using ([,a-zA-Z0-9%_-]*) to capture variables in a route. Journey (the Rails router) uses ([^./?]+).
I suggest using a blacklist, or we'll continue to see more bugs in this area, e.g. '/foo/:bar' won't match '/foo/你好' which seems a shame.

[cburgdorf]

Thanks for jumping on it. Do you know how express.js handles it? Do you know other frameworks/routers that handle it this way? This would break routes such as /format/:format/:file, no? If I let that match against /format/plain/some.txt then request.param("format") will be txt instead of plain, right?

[Ryman]

Yes, good catch, I've pushed a commit to address that, checking if :format already exists in the route, and if not add it.

Here's how rails handles it:
https://github.com/rails/rails/blob/6d86762fd8f83896a6932614e9ac9bdc42102805/actionpack/lib/action_dispatch/routing/mapper.rb#L133

It has a fair amount of configuration options, and they handle things like explicit trailing slashes, which I think we should discuss in another issue if we want to restrict that additionally.

Express on the other hand seems to only restrict '/' unless you have a dot prefix (for some kind of escaping functionality)
https://github.com/pillarjs/path-to-regexp/blob/master/index.js#L129

So, by default, rails forbids . / ? while express limits /.

I think it's worth pointing out that rails does split out :format so it can do interesting default handling for a number of things, see respond_with

[cburgdorf]

Ok, seams reasonable. Merged it.

[Ryman]

This was never actually merged? Will need a rebase.

[cburgdorf]

Oh noooees, what did I do back then :'(

[Ryman]

Just looked into the history on this one, it did merge and then encountered a bad rebase or something? It gets nuked out during a PR from ME 😞 #94, specifically this commit Ryman@f12ab9a.

I guess git was overzealous when a file got moved and didn't warn me about a merge conflict, still kind of shocking to not have noticed (and the tests got nuked so nothing failed out). So definitely not a forgotten merge anyway @cburgdorf!

So, I'm going to re-add the changes in a new PR since rebasing this doesn't do anything as it's already in master's history.