ruby-grape / grape / 33382102206

97%

master: 97%

push

github

Test the path-normalizer fast path without a regexp

`Grape::Util::PathNormalizer.call` runs twice per request — once in
`Versioner::Path#before`, once in `Router#call` — and almost always returns the
path untouched. The guard that decides this matched `%r{%|//}`, which is one
alternation over the whole string:

    return path if path.start_with?('/') && !(path.end_with?('/') || path.match?(%r{%|//}))

Two `String#include?` calls answer the same question and stay in C without
building a match. Measured in one process, on the predicate alone:

    realistic path (41 chars)    regexp 313 ns   ->   include? 217 ns   1.44x
    short path (13 chars)        regexp 194 ns   ->   include? 181 ns   1.07x

The gain grows with path length, which is the direction real APIs go. No
allocation change either way.

One behavioural difference worth naming: `String#include?` does not validate
encoding, while `String#match?` does. A PATH_INFO holding an invalid byte
sequence used to raise `ArgumentError` here; it now passes through and raises
the same `ArgumentError` from `Router#match?` instead, one frame later. A path
served by a forward-match route (a bare Rack app mounted with `mount`), which
never reaches a regexp, now goes through rather than raising. Nothing
percent-encodes to invalid UTF-8, so this needs a client sending raw bytes in
the request target.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

1238 of 1330 branches covered (93.08%)

Branch coverage included in aggregate %.

1 of 1 new or added line in 1 file covered. (100.0%)

3897 of 3965 relevant lines covered (98.28%)

27164.23 hits per line