(This seems to have been a contentious issue — please don't hate me.)

This addresses an issue — reported before in #1972 — namely that werkzeug.utils.append_slash_redirect does not work correctly if PATH_INFO contains internal slashes.

Suppose a request comes in for http://example.com/app/foo/bar. Assume this makes it to the WSGI app with environ["SCRIPT_NAME"] = "/app" and environ["PATH_INFO"] = "/foo/bar". The app, in order to append a slash to the URL returns append_slash_redirect(environ). As things stand, this issues a redirect to the relative path "foo/bar/". That path gets interpreted relative to the base URL implied by the original request ("http://example.com/app/foo/bar") resulting in a final location of "http://example.com/app/foo/foo/bar/". This is not quite what is wanted — one foo is enough for us.

The solution is to redirect to a relative path (as is currently done), but redirect to a relative path that contains only the trailing component PATH_INFO.

This PR fixes that and includes new tests that exercise the problem.

Relation to Prior Work

Note that this issue is subtly different than that purportedly "fixed" by PR #1538. PR #1538, as demonstrated by the tests included in that PR wants to redirect to an absolute path based on PATH_INFO. This results in (incorrectly) discarding any leading path components that may be in SCRIPT_NAME.

There is also #1842. Due to its brevity, it is unclear precisely what issue is being described therein, but the proposed fix is the same as the (incorrect) solution proposed in #1538.

Issues Fixed

• fixes function append_slash_redirect misredirects #1972

Checklist

• Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
• [n/a] Add or update relevant docs, in the docs folder and in code.
• Add an entry in CHANGES.rst summarizing the change and linking to the issue.
• [n/a] Add .. versionchanged:: entries in any relevant code docs.
• Run pre-commit hooks and fix any issues.
• Run pytest and tox, no tests failed.