[wleeaf]

resolve_relative_location removes . and .. segments when it merges a relative-path Location with the request path. A Location that starts with /, or an absolute URI, is passed to parse_url unchanged, though, and its path is requested as is. So a redirect to /dir/../target?x=1 requests /dir/../target?x=1, and so does http://host:port/dir/./../target. A server that doesn't normalize the path itself (cpp-httplib's own router doesn't) answers 404. RFC 3986 section 5.2.2 applies remove_dot_segments to the target path of every reference that has a path, not only relative ones (examples /./g -> http://a/g and /../g -> http://a/g in section 5.4.2). Browsers and curl request /target here.

The change moves the existing dot-segment loop into detail::remove_dot_segments without changing its behaviour. resolve_relative_location now calls it, and ClientImpl::redirect applies it to the parsed path when the path starts with /. Relative locations are handled as before, so the resolve_relative_location expectations stay the same.

New tests:

• RedirectTest.RemoveDotSegments: the RFC 3986 section 5.2.4 examples, plus /./g, /../g, /.., /a/b/.. and a path without dot segments.
• RedirectTest.AbsoluteLocationIsNormalized: redirects to /dir/../target?x=1 and to http://localhost:<port>/dir/./../target must reach /target. Against the current header, both get 404, because the server receives the unnormalized path.

make test builds without warnings. The test binary passes 1051 tests with --gtest_filter=-*Online*. git clang-format reports no changes.

[yhirose]

Thanks