Entry tags:
lookup-routing: tool to help navigate the routing system
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
It does several things.
First, you can easily find out which file handles what page (e.g., /nav, /nav/create, /rename, /admin, /post, etc).
$ lookup-routing /admin
app: /admin is a redirect to /admin/
app: /admin/ is defined in the file cgi-bin/DW/Controller/Admin.pm, and using the handler sub admin_handler
This is useful if you're working on a bug that's been reported on /some/path/here, and you want to know which file to open up first.
(Psst If "lookup-routing /some/path" doesn't work, it is probably a BML file. Try htdocs/some/path.bml)
--verbose gives you a much more detailed view:
$ lookup-routing /nav/create
app: /nav/create is defined in the file cgi-bin/DW/Controller/Nav.pm, and using the handler sub nav_handler
* Default Format: html
* Enabled for formats: html, json
* Enabled For: app
* Regex: (?-xism:^/nav(?:/([a-z]*))?$)
* Matched Subpatterns:
'create'
Some things that can be inferred from this information:
- /nav/create will show you the HTML version of the page, because html is the default format
- /nav/create.html, /nav/create.json both work
- this page is on www.dreamwidth.org, not exampleusername.dreamwidth.org
- the regex match gives you a "create" argument. Maybe if you type in /nav/shop, /nav/somethingelse, those will match with the same handler?
In particular, the things in the matched subpattern section are passed as arguments to the handlers. For example, from cgi-bin/DW/Controller/Nav.pm:
sub nav_handler {
my ( $opts, $cat ) = @_;
...
}
$opts contains routing information; see cgi-bin/DW/Routing/CallInfo.pm if you want to know more. The more interesting bit for us here is that the second variable, $cat, is "create" for /nav/create.
It's a quick way to get a list of what arguments will be available to your handler when you visit a URL, and it may help you track down anything wrong with your regexes, or make it easier to find out why a handler isn't working.
If lookup-routing /expected/working/path says /expected/working/path is not defined, then that path was never registered. Could be a typo somewhere
If lookup-routing /some/path works but somehow triggers the wrong handler, that's easier to discover too
If lookup-routing /post/exampleusername/1234 works, but your matched subpatterns section only contains "exampleusername" maybe there are missing parentheses to capture the 1234
If the expected path leads to the expected handler, maybe you need to sync over your changes to live?
If the expected path leads to the expected handler and you've synced over changes to live, there could be something wrong within the handler itself...
Second, you can get a list of everything in the routing table, using the --list argument:
$ lookup-routing --list
You can filter the list down to either those that use regex matching, or those that use string-matching:
$ lookup-routing --list --regex
$ lookup-routing --list --string
You can also filter down to just those pages in user-space, app-space, or ssl using --role=user, --role=app, --role=ssl, respectively. Default is --role=all.
There are --user, --app, --ssl shortcuts which do the same as their --role=... equivalents.
$ lookup-routing --list --user # lists paths handled by the routing system that follow the form http://exampleusername.dreamwidth.org/some/path/here
$ lookup-routing --list --app # lists paths handled by the routing system that follow the form http://www.dreamwidth.org/some/path/here
$ lookup-routing --list --ssl # lists paths routing system that use https
And third, you can get a quick summary of stats by running
lookup-routing --stats
A quick reminder of which arguments to use is available by running:
lookup-routing --help
Very detailed usage instructions can be found by running:
lookup-routing --help --verbose
If you haven't already installed the dev tools yet, see the Dev Tools wiki page. If you've installed the dev tools before, make sure to update your code, to pull in the changes.