Spec recommendation vs implementation inconsistency in resource URL trailing slash handling

[younaman]

Question

Description:
According to the specification (and RFC 8707 guidance), implementations SHOULD consistently use the form without the trailing slash for better interoperability, unless the trailing slash is semantically significant.

However, in the current implementation of check_resource_allowed, both requested_path and configured_path are normalized by adding a trailing slash before comparison:

if not requested_path.endswith("/"):
    requested_path += "/"
if not configured_path.endswith("/"):
    configured_path += "/"
return requested_path.startswith(configured_path)

This ensures correct boundary checks (avoiding /api123 matching /api), but it looks contradictory to the spec’s recommendation (which suggests preferring non-slash-terminated form).

Expected behavior:

• Resource URLs should be canonicalized to the “no trailing slash” form wherever possible (e.g., inside resource_url_from_server_url), except when semantically required.
• The comparison logic in check_resource_allowed can still normalize with / internally for boundary safety, but ideally this should be documented clearly to avoid confusion.

Actual behavior:

• Implementation internally adds a trailing slash before comparison, which appears to promote the opposite style compared to the spec recommendation.

Suggestion:

1. Canonicalize configured/requested URLs to the “no trailing slash” form (except root path /) when generating or storing resource URLs.
2. Keep the internal endswith("/") normalization in check_resource_allowed for safe prefix matching.
3. Update docstrings or comments to clarify why the implementation diverges from the spec’s recommended form, to avoid confusion for implementers.

Additional Context

No response