Before merging this patch, we need two things:

• fix the Apache dumper;
• use regexes for the _method requirement (we can probably only support *|*|* as suggested on the mailing-list).

Another thought, can we get rid of the HttpException in favor of a NotFoundResponse class?

Throwing an exception allows Routing to remain decoupled from HttpFoundation, a separation we should maintain.

I see, this makes sense, but instead of converting the NotFoundException to a NotFoundHttpException, we could directly return a NotFoundResponse at this point, no? This would save us the round trip to the exception controller and embrace the response concept we have chosen for Symfony2.

I considered this when working on this patch, but having an event and default controller for any >= 400 response is a nice feature I'd rather not get rid of. It should be easy for users to render custom error pages.

What if someone returns a response with a >= 400 status code from the controller? That wouldn't go to the exception controller.

I think you can still accomplish custom error pages using a core.response listener. That seems to be more in line with the Symfony2 credo: "If you want to change the response, listen to core.response."

Now, that we have finally decided on this credo, we should be consistent and embrace it.

I could see us going either way under the credo "as soon as we have a response we're done." I think it's better that we throw an exception so the user has only one integration point when customizing error pages (the controller behind core.exception) rather than one for 5xx errors and another for 4xx errors.

Hehe ;) can we ensure somehow that users cannot return 4xx responses from their controllers? Because otherwise some users will create their own NotFoundResponse class while others will throw an exception, I think it's better and less confusing if we only have one way to achieve this.

I don't see any issue with a controller returning a >= 400 response, it just won't trigger core.exception, obviously.

One thing that concerns me with redirect exceptions is that you could throw them from your model or any deepest level of code and affect routing, seems weird to me

There's no such thing as a redirect exception... is there?

sorry, I mean NotFoundException et al. Any exception affecting response, that seems weird

I also think thats its more important to try and funnel all such "exceptional" cases through the exception controller if the user isnt explicit (aka doesnt create a Response instance manually).

Johannes has a valid point (not really related to this pull request). The current behavior of the framework is different if you just return a 404 response or if you throw and exception.

Kris: Besides two obvious changes I made to the last commit, can I merge this pull request or do you still need to work on the Apache dumper?

I've fixed those two things, but the Apache dumper is not ready yet.

In this context I would also like to mention: http://webmachine.basho.com/diagram.html
Would be quite cool if we could try to sensibly implement as much as possible in core and then work on the RestBundle idea to implement the remaining stuff easily inside the user code.

This is ready to be merged now. Please note I've changed Routing's ApacheMatcherDumper to use %{REQUEST_URI} rather than %{PATH_INFO}, simply because I wasn't able to get the latter to work reliably. This also fixes an issue with the mechanism that redirects to append a trailing slash, which we redirecting with %{PATH_INFO} rather than %{REQUEST_URI}. This adds a new base_uri option to the dumper and dump command.

I've updated the fixture. All tests are passing.