Support request method in route matching (close #535). #794

wants to merge 1 commit into


None yet

3 participants


No description provided.

Union of RAD member

Okay, what are the implications, if any, for generating URLs with this? And what if you want your default to be for routes to accept any HTTP method (like I normally want)?

@jails jails closed this Jan 23, 2013

explanation in #535.


i think there's an even 'lighter' fix:

        public function compile() {

e.g. after compiling the route just unset the 'http:method' from _match. i noticed that a route with a param (e.g. /foo/{:id:\d+}) will cause that key removed from _match anyway (see Route::compile() and its last row, however 'simple' routes would return from compile() sooner).

with 'http:method' removed all the matching would work as before and you still can add http:method (which will be checked against a request in Route::parse()). i think this makes sense e.g. when generating an url (e.g. in a template) it's inconvenient to pass http-method.

if we agree that this is a bug in lithium (the current implementation itself isn't consistent, because you need to pass http-method if and only if you don't have a param in your route) i think the only thing needs to be modified is that in Route::compile() the $this->_match = $this->_params; line should go after the for loop that cleans params (this is also done by this PR). however i'm not sure about the logic, whether it should match http-method explicitly or not, should GET be a default, etc. (as i said i prefer matching without http-method when generating routes, but dispatching should check http-method).

(please note i'm using 0.11 right now)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment