Fix append_slash_redirect when PATH_INFO has internal slashes

[dairiki]

(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.

[davidism]

Thank you, this finally makes sense. The issue is that Request.autocorrect_location_header uses the urljoin behavior to join the relative redirect URL to the full request path. The full path includes both SCRIPT_NAME and PATH_INFO, but the redirect was also using the entire PATH_INFO. Relative URL join behavior is to replace only the last segment of the path with the new relative path, so append_slash_redirect needs to only return that last segment.

[dairiki]

@davidism Yes, I think you have found exactly where the urljoin happens. (That is the correct behavior — relative URLs should be interpreted relative to the full request path. Of note, it would also be correct to pass the relative URL in the Location header back to the browser unmolested — relative URLs are allowed in the Location header, and they are to be interpreted relative to the request URL. Ref: RFC 7231.)

Anyhow, I've just rebased this PR onto the current main.