Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This refactoring avoids ever parsing GET/POST parameters to obtain the Rails routing information required for the `request.action`, `request.controller`, and `request.route` fields. This is accomplished in two ways: 1. Use `ActionDispatch::Request#path_parameters` instead of `ActionDispatch::Request#params`. The former is the subset of data we need for `request.action` + `request.controller`, and in fact are the values merged into the latter hash after `#params` parses the normal GET/POST parameters. So we can avoid the extraneous parsing by just getting the path parameters straight from the horse's mouth. 2. Call `ActionDispatch::Journey::Router#recognize` on a simplified request that *only* contains the necessary routing information. The `#recognize` method will yield the `ActionDispatch::Request#params` when it matches a route, which again triggers the GET/POST parsing. But we don't care about the HTTP parameters. So instead I copied the approach of `ActionDispatch::Routing::RouteSet#recognize_path`, which reconstructs a simplified request with just the information that it needs. (Unfortunately we can't use `#recognize_path` directly because instead of returning the route it returns the path parameters, which we can already get directly from `#path_parameters`.) This accomplishes several things: * Fixes honeycombio#62, since we don't get a chance to erroneously fall back to GET/POST parameters in the event that the routing information is missing (due to requests to unrecognized routes). * Fixes honeycombio#31, since the bug ultimately comes from the twirp gem causing POST parameter parsing to fail. But if we never parse the HTTP parameters, no problem. This is a more direct workaround than honeycombio#39, but ultimately is a problem that should be fixed upstream. * Fixes honeycombio#49, since the parameter encoding won't matter if we never try to parse them. Renders honeycombio#50 unnecessary, since we won't have a chance to trigger the exceptions in question. * Gives us more data in more situations. The new implementation of the `request.route` field now comes up non-nil in the event of errors because we use the `ActionDispatch::Request#original_fullpath` and not the `#path_info` that gets [rewritten by `ActionDispatch::ShowExceptions`](https://github.com/rails/rails/blob/758e4f8406e680a6cbf21b170749202c537a2576/actionpack/lib/action_dispatch/middleware/show_exceptions.rb#L49). * Gives us more data in more Rails versions. With the addition of actual tests for the field values, it became clear that `request.route` was missing in Rails 4, simply because of an interface change introduced in Rails 5.
- Loading branch information