fix: Clarify handling of / in the specification
#687
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change clarifies the meaning of “excessive slashes” (`/`) in `namespace`, `name`, and `subpath` by adding explicit requirements for parsers: * **Namespace**: Parsers must ignore all empty segments. Leading and trailing slashes are just special cases of empty segments (e.g., `/foo/` → `["", "foo", ""]`). * **Name**: Parsers must ignore trailing slashes. To avoid ambiguity when multiple leading slashes appear (which some parsers might interpret as part of the `name` and others as part of the `namespace`), parsers should remove them in either case. For example: * `pkg:type/namespace//name` → the intended namespace is `namespace/` and the name is `name`, but some parsers might incorrectly treat the name as `/name`. * `pkg:type//name` → the intended namespace is empty, and the name is `name`, but some parsers might incorrectly treat the name as `/name`. * **Subpath**: Parsers must apply the same rule and ignore empty segments. These changes aim to resolve ambiguities in the current specification. For example, under the existing wording: * Leading and trailing slashes `/` “should be stripped in the canonical form,” but it is unclear whether this refers to the canonical form of the entire PURL or only the encoded `namespace`. * At the same time, those slashes are described as not being part of the `namespace`. The revision also extends the specification by requiring parsers to strip consecutive slashes that appear within the encoded `namespace` and `subpath`. This change addresses part of the ambiguities described in package-url#584 by eliminating the category of “invalid but tolerated” PURLs. Instead, it shifts the responsibility to parsers, which must leniently normalize PURLs with excessive slashes into valid ones. Importantly, this normalization can be applied without requiring a full parser.
booniepepper
approved these changes
Oct 24, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change clarifies the meaning of “excessive slashes” (
/) innamespace,name, andsubpathby adding explicit requirements for parsers:Namespace: Parsers must ignore all empty segments. Leading and trailing slashes are just special cases of empty segments (e.g.,
/foo/→["", "foo", ""]).Name: Parsers must ignore trailing slashes. To avoid ambiguity when multiple leading slashes appear (which some parsers might interpret as part of the
nameand others as part of thenamespace), parsers should remove them in either case. For example:pkg:type/namespace//name→ the intended namespace isnamespace/and the name isname, but some parsers might incorrectly treat the name as/name.pkg:type//name→ the intended namespace is empty, and the name isname, but some parsers might incorrectly treat the name as/name.Subpath: Parsers must apply the same rule and ignore empty segments.
These changes aim to resolve ambiguities in the current specification. For example, under the existing wording:
/“should be stripped in the canonical form,” but it is unclear whether this refers to the canonical form of the entire PURL or only the encodednamespace.namespace.The revision also extends the specification by requiring parsers to strip consecutive slashes that appear within the encoded
namespaceandsubpath.This change addresses part of the ambiguities described in #584 by eliminating the category of “invalid but tolerated” PURLs. Instead, it shifts the responsibility to parsers, which must leniently normalize PURLs with excessive slashes into valid ones. Importantly, this normalization can be applied without requiring a full parser.