Routing based on the full request object #4020

Closed
Crell opened this Issue Apr 20, 2012 · 7 comments

5 participants

@Crell

Hi folks. I want to get some feedback on this before I go any further with it.

In Drupal, we do all sorts of unholy things to the incoming path. Most notably, the path is aliased (so that internal code need deal with only a single router item, node/{node}, where the user only ever sees /about-us), and we sometimes stick a prefix onto it to specify the language (/en/about-us and /fr/about-us). So the path that gets used for routing often doesn't look a thing like the path in the original HTTP request, and when code tries to generate a URL to node/5, what actually ends up in the page could be /de/about-us/early-years.

I'm trying to figure out how to do that in the HttpKernel model. My initial thought was to have an early kernel.request listener that created a new request object based off of the original, but with a mutated path to resolve the aliasing and overwriting the Language header with information from the path, if appropriate. (The language can come from the header, the request path, or the current user's settings, just to keep life interesting.)

However, I determined that you cannot change the Request object from a kernel.request listener. I suppose that makes sense. The request object's path also cannot be changed.

I could run a subrequest from the listener, but that seems rather excessive.

Talking about it in #symfony-dev the other night, a few people suggested treating the request as immutable and just throwing the "resolved" path into attributes, then doing all of the routing based off of that. There's certainly something to that, and then we could put the resolved language there, too, along with other such things. However, the request object is never passed to UrlMatcher. The RequestContext object is, which doesn't include attributes.

The only way around that is to make my own UrlMatcher class (which we already are) and our own RouterListener, and then have a fake RequestContext object that we never use because it's required by the UrlMatcherInterface. That feels rather ugly to me. A gist of it is here (including some Drupal cruft; pay it no mind, it will go away eventually):

https://gist.github.com/2418886

Johannes suggested that an option to pass a full request object to the matcher makes sense for Symfony directly, since there's all sorts of useful information there that the request context object lacks.

So before I go any further down this path, is any of the above making sense? Is that a decent approach to take? Would something like this be more useful directly in Symfony rather than in Drupal-specific subclasses? Is there some better option I'm totally missing?

I'd love to get some feedback here before I go down the wrong rabbit hole. :-)

@stof
Symfony member

You don't need your own UrlMatcher. You simply need to use your own RouterListener instead of the listener provided in HttpKernel, to use a different path when calling the Router (putting it in the RequestContext instead of putting the real Request path).

Passing the Request object to the router would add a dependency to the HttpFoundation component in Routing whereas it is standalone currently, and it would be a BC break.

@schmittjoh

I think we need a mechanism to do routing not only based on the path, but also on the request headers (including cookies).

This is especially necessary when doing a more complex form of content negotation (interesting for FOSRestBundle, and also JMSI18nRoutingBundle).

So my quick suggestion was to do matching based on the request object. I think most people that use the Routing component will also use the HttpFoundation component (the latter being probably the first candidate if someone looks at using Symfony component). The alternative is to copy more of the request object to the RequestContext object, but then what is the context of a request, and what is the request?

@Crell

Stof: Right, that's why I agree it should not be put into the default UrlMatcher. However, as schmittjoh notes there's plenty of things to route on besides the path. Right now, that seems to be far more work than it should be.

The alternative would be to allow the request object to be changed in kernel.request, in which case I can just build whatever new request I want and everything else works as-is.

@fabpot
Symfony member

see fabpot/Silex#183 for an other issue on the same topic.

@mgatto

Too cool; thanks!

@Crell

For the time being I've subclassed the RouterListener to pass our processed attribute rather than getPathInfo() to the matcher. That's not a long-term solution, though, I think.

@fabpot fabpot added a commit that referenced this issue Jun 9, 2012
@fabpot fabpot merged branch niklasf/request-matcher-interface (PR #4363)
Commits
-------

2277500 [Routing][HttpKernel] Add RequestMatcherInterface.

Discussion
----------

[Routing][HttpKernel] Add RequestMatcherInterface.

First try at implementing #4351.

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Fixes the following tickets: -
Todo: -
License of the code: MIT

---------------------------------------------------------------------------

by travisbot at 2012-05-21T19:37:07Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1392716) (merged 457496db into ea33d4d).

---------------------------------------------------------------------------

by travisbot at 2012-05-21T19:47:51Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1392939) (merged 78effa98 into ea33d4d).

---------------------------------------------------------------------------

by everzet at 2012-05-21T20:17:03Z

No tests?

---------------------------------------------------------------------------

by travisbot at 2012-05-21T20:18:18Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1393392) (merged 6564fb6a into ea33d4d).

---------------------------------------------------------------------------

by schmittjoh at 2012-05-21T20:35:14Z

You need to remove the type-hint from the constructor, and probably add an exception instead where the matching methods are called to ensure that either ``UrlMatcherInterface``, or ``RequestMatcherInterface`` were passed. Alternatively, you could also add such a check to the constructor.

---------------------------------------------------------------------------

by fabpot at 2012-05-22T06:52:01Z

related to symfony/symfony#4020

---------------------------------------------------------------------------

by niklasf at 2012-05-25T11:11:45Z

Reverted the changes to UrlMatcher.php.

---------------------------------------------------------------------------

by fabpot at 2012-05-25T12:46:06Z

@niklasf: it looks good now except for the listener constructor (see @schmittjoh suggestion above). Can you fix that and add some unit tests to ensure that everything works as expected? Thanks.

---------------------------------------------------------------------------

by stof at 2012-05-25T12:52:59Z

Another solution could be to make the ``RequestMatcherInterface`` extend the ``MatcherInterface`` to keep the typehint in the constructor

---------------------------------------------------------------------------

by fabpot at 2012-05-25T13:52:26Z

I thought about that as well, but that does not make sense.

---------------------------------------------------------------------------

by stof at 2012-05-25T14:12:19Z

Well, the RouterInterface extends UrlMatcherInterface anyway (and it should stay this way as it would be a huge BC break) so I guess most people will implement both interfaces when implementing the RquestMatcherInterface

---------------------------------------------------------------------------

by travisbot at 2012-05-25T15:26:22Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1433963) (merged 8f36204c into ff4d446).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T15:33:13Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1433996) (merged 6d2f2cd9 into ff4d446).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T15:39:01Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1434060) (merged 3c1d89e2 into ff4d446).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T22:06:34Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1437398) (merged 3ab997c1 into ff4d446).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T22:06:47Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1437385) (merged d8c0e387 into ff4d446).

---------------------------------------------------------------------------

by fabpot at 2012-05-26T06:41:31Z

Can you add a note in the CHANGELOG of the component?

---------------------------------------------------------------------------

by travisbot at 2012-05-26T08:12:40Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1440435) (merged c7458733 into 9e95199).

---------------------------------------------------------------------------

by niklasf at 2012-05-26T08:14:41Z

@fabpot: Sorry, not sure how: Under 2.1.0 or in a new section? As the first or last entry of the list?

---------------------------------------------------------------------------

by stof at 2012-05-26T10:20:23Z

@niklasf the new interface should be mentioned in the changelog of the Routing component

---------------------------------------------------------------------------

by travisbot at 2012-05-26T10:30:06Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1440837) (merged 34ea86a9 into 9e95199).

---------------------------------------------------------------------------

by niklasf at 2012-06-02T15:27:01Z

Ah ... so there were two pitfalls:

- PHPUnit clones the arguments of mocked functions. So they wouldn't equal.
- createGetResponseEventForUri() disables routing on purpose. So not using that helper, now.

Tests should be passing.

---------------------------------------------------------------------------

by travisbot at 2012-06-02T15:30:28Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1509054) (merged 7fab0118 into 1541fe2).
1787992
@fabpot fabpot added a commit to symfony/routing that referenced this issue Jun 10, 2012
@fabpot fabpot merged branch niklasf/request-matcher-interface (PR #4363)
Commits
-------

2277500 [Routing][HttpKernel] Add RequestMatcherInterface.

Discussion
----------

[Routing][HttpKernel] Add RequestMatcherInterface.

First try at implementing #4351.

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Fixes the following tickets: -
Todo: -
License of the code: MIT

---------------------------------------------------------------------------

by travisbot at 2012-05-21T19:37:07Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1392716) (merged 457496db into ea33d4d3).

---------------------------------------------------------------------------

by travisbot at 2012-05-21T19:47:51Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1392939) (merged 78effa98 into ea33d4d3).

---------------------------------------------------------------------------

by everzet at 2012-05-21T20:17:03Z

No tests?

---------------------------------------------------------------------------

by travisbot at 2012-05-21T20:18:18Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1393392) (merged 6564fb6a into ea33d4d3).

---------------------------------------------------------------------------

by schmittjoh at 2012-05-21T20:35:14Z

You need to remove the type-hint from the constructor, and probably add an exception instead where the matching methods are called to ensure that either ``UrlMatcherInterface``, or ``RequestMatcherInterface`` were passed. Alternatively, you could also add such a check to the constructor.

---------------------------------------------------------------------------

by fabpot at 2012-05-22T06:52:01Z

related to symfony/symfony#4020

---------------------------------------------------------------------------

by niklasf at 2012-05-25T11:11:45Z

Reverted the changes to UrlMatcher.php.

---------------------------------------------------------------------------

by fabpot at 2012-05-25T12:46:06Z

@niklasf: it looks good now except for the listener constructor (see @schmittjoh suggestion above). Can you fix that and add some unit tests to ensure that everything works as expected? Thanks.

---------------------------------------------------------------------------

by stof at 2012-05-25T12:52:59Z

Another solution could be to make the ``RequestMatcherInterface`` extend the ``MatcherInterface`` to keep the typehint in the constructor

---------------------------------------------------------------------------

by fabpot at 2012-05-25T13:52:26Z

I thought about that as well, but that does not make sense.

---------------------------------------------------------------------------

by stof at 2012-05-25T14:12:19Z

Well, the RouterInterface extends UrlMatcherInterface anyway (and it should stay this way as it would be a huge BC break) so I guess most people will implement both interfaces when implementing the RquestMatcherInterface

---------------------------------------------------------------------------

by travisbot at 2012-05-25T15:26:22Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1433963) (merged 8f36204c into ff4d446c).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T15:33:13Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1433996) (merged 6d2f2cd9 into ff4d446c).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T15:39:01Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1434060) (merged 3c1d89e2 into ff4d446c).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T22:06:34Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1437398) (merged 3ab997c1 into ff4d446c).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T22:06:47Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1437385) (merged d8c0e387 into ff4d446c).

---------------------------------------------------------------------------

by fabpot at 2012-05-26T06:41:31Z

Can you add a note in the CHANGELOG of the component?

---------------------------------------------------------------------------

by travisbot at 2012-05-26T08:12:40Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1440435) (merged c7458733 into 9e951991).

---------------------------------------------------------------------------

by niklasf at 2012-05-26T08:14:41Z

@fabpot: Sorry, not sure how: Under 2.1.0 or in a new section? As the first or last entry of the list?

---------------------------------------------------------------------------

by stof at 2012-05-26T10:20:23Z

@niklasf the new interface should be mentioned in the changelog of the Routing component

---------------------------------------------------------------------------

by travisbot at 2012-05-26T10:30:06Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1440837) (merged 34ea86a9 into 9e951991).

---------------------------------------------------------------------------

by niklasf at 2012-06-02T15:27:01Z

Ah ... so there were two pitfalls:

- PHPUnit clones the arguments of mocked functions. So they wouldn't equal.
- createGetResponseEventForUri() disables routing on purpose. So not using that helper, now.

Tests should be passing.

---------------------------------------------------------------------------

by travisbot at 2012-06-02T15:30:28Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1509054) (merged 7fab0118 into 1541fe26).
4eef37e
@Crell

With the request matcher interface, I think this issue is resolved. Thanks, all!

@Crell Crell closed this Jul 11, 2012
@mmucklo mmucklo pushed a commit that referenced this issue May 23, 2013
@fabpot fabpot merged branch niklasf/request-matcher-interface (PR #4363)
Commits
-------

2277500 [Routing][HttpKernel] Add RequestMatcherInterface.

Discussion
----------

[Routing][HttpKernel] Add RequestMatcherInterface.

First try at implementing #4351.

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Fixes the following tickets: -
Todo: -
License of the code: MIT

---------------------------------------------------------------------------

by travisbot at 2012-05-21T19:37:07Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1392716) (merged 457496db into ea33d4d).

---------------------------------------------------------------------------

by travisbot at 2012-05-21T19:47:51Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1392939) (merged 78effa98 into ea33d4d).

---------------------------------------------------------------------------

by everzet at 2012-05-21T20:17:03Z

No tests?

---------------------------------------------------------------------------

by travisbot at 2012-05-21T20:18:18Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1393392) (merged 6564fb6a into ea33d4d).

---------------------------------------------------------------------------

by schmittjoh at 2012-05-21T20:35:14Z

You need to remove the type-hint from the constructor, and probably add an exception instead where the matching methods are called to ensure that either ``UrlMatcherInterface``, or ``RequestMatcherInterface`` were passed. Alternatively, you could also add such a check to the constructor.

---------------------------------------------------------------------------

by fabpot at 2012-05-22T06:52:01Z

related to symfony/symfony#4020

---------------------------------------------------------------------------

by niklasf at 2012-05-25T11:11:45Z

Reverted the changes to UrlMatcher.php.

---------------------------------------------------------------------------

by fabpot at 2012-05-25T12:46:06Z

@niklasf: it looks good now except for the listener constructor (see @schmittjoh suggestion above). Can you fix that and add some unit tests to ensure that everything works as expected? Thanks.

---------------------------------------------------------------------------

by stof at 2012-05-25T12:52:59Z

Another solution could be to make the ``RequestMatcherInterface`` extend the ``MatcherInterface`` to keep the typehint in the constructor

---------------------------------------------------------------------------

by fabpot at 2012-05-25T13:52:26Z

I thought about that as well, but that does not make sense.

---------------------------------------------------------------------------

by stof at 2012-05-25T14:12:19Z

Well, the RouterInterface extends UrlMatcherInterface anyway (and it should stay this way as it would be a huge BC break) so I guess most people will implement both interfaces when implementing the RquestMatcherInterface

---------------------------------------------------------------------------

by travisbot at 2012-05-25T15:26:22Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1433963) (merged 8f36204c into ff4d446).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T15:33:13Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1433996) (merged 6d2f2cd9 into ff4d446).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T15:39:01Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1434060) (merged 3c1d89e2 into ff4d446).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T22:06:34Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1437398) (merged 3ab997c1 into ff4d446).

---------------------------------------------------------------------------

by travisbot at 2012-05-25T22:06:47Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1437385) (merged d8c0e387 into ff4d446).

---------------------------------------------------------------------------

by fabpot at 2012-05-26T06:41:31Z

Can you add a note in the CHANGELOG of the component?

---------------------------------------------------------------------------

by travisbot at 2012-05-26T08:12:40Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1440435) (merged c7458733 into 9e95199).

---------------------------------------------------------------------------

by niklasf at 2012-05-26T08:14:41Z

@fabpot: Sorry, not sure how: Under 2.1.0 or in a new section? As the first or last entry of the list?

---------------------------------------------------------------------------

by stof at 2012-05-26T10:20:23Z

@niklasf the new interface should be mentioned in the changelog of the Routing component

---------------------------------------------------------------------------

by travisbot at 2012-05-26T10:30:06Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1440837) (merged 34ea86a9 into 9e95199).

---------------------------------------------------------------------------

by niklasf at 2012-06-02T15:27:01Z

Ah ... so there were two pitfalls:

- PHPUnit clones the arguments of mocked functions. So they wouldn't equal.
- createGetResponseEventForUri() disables routing on purpose. So not using that helper, now.

Tests should be passing.

---------------------------------------------------------------------------

by travisbot at 2012-06-02T15:30:28Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1509054) (merged 7fab0118 into 1541fe2).
086af91
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment