Skip to content

Namespace/subpath: simplify parsing #452

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

ppkarwasz
Copy link
Contributor

This PR:

  • Uniformizes the treatment of namespace and subpath: all segments that are empty or equal to one of . or .. should be discarded.
  • Moves the check for . and .. segments after UTF-8 decoding. This ensures that overlong encoding of . (like %C0%AE, %E0%80%AE, %F0%80%80%AE) are also discarded.
  • Requires the parser to throw an error if an (percent-encoded) solidus / is encountered in any path segment.

This PR:

- Uniformizes the treatment of `namespace` and `subpath`: all segments that are empty or equal to one of `.` or `..` should be discarded.
- Moves the check for `.` and `..` segments after UTF-8 decoding. This ensures that overlong encoding of `.` (like `%C0%AE`, `%E0%80%AE`, `%F0%80%80%AE`) are also discarded.
- Requires the parser to throw an error if an (percent-encoded) solidus `/` is encountered in any path segment.

Signed-off-by: Piotr P. Karwasz <[email protected]>
@jkowalleck
Copy link
Member

jkowalleck commented Apr 9, 2025

Looks like this would modify the spec as discussed in #448 , and therefore fixes #448

@jkowalleck jkowalleck linked an issue Apr 9, 2025 that may be closed by this pull request
@matt-phylum
Copy link
Contributor

Does this simplify namespaces? This seems like it only makes namespaces more complicated. Unlike subpaths, namespaces do not care about . or .. segments (and to do so would be a breaking change) so there is no reason to treat %2F and / differently.

@jkowalleck
Copy link
Member

Seams about right.

Anyway, @ppkarwasz, could you close this particular PR and split it intwo two separate ones, one for each of the scopes?

These two PRs could then be worked on independently in their own pace.

@ppkarwasz
Copy link
Contributor Author

ppkarwasz commented Apr 10, 2025

I am closing this, since I split it as suggested into:

@ppkarwasz ppkarwasz closed this Apr 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

revisit "subpath"'s "serializer" and "parser" sections
3 participants