fix: redefine opaque pathname detection for custom protocols #62
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.
Summary
This PR fixes issue denoland/deno#29935 by redefining how opaque pathnames are detected for custom protocols.
Changes
Modified opaque pathname detection logic to treat pathnames as non-opaque when:
Updated both
process_pathname_init
and the pathname compilation logic to use consistent criteriaTest Plan
issue61
that verifies:myhttp://example.com/:directory/:file
→ pathname:/:directory/:file
(not escaped)myfile:///test
→ pathname:/test
(not escaped)Background
Previously, custom protocols like
myprotocol://example.com/:directory/:file
would have their pathname pattern syntax (colons) incorrectly escaped as%2F:directory%2F:file
. This was because the logic only considered whether the protocol was a "special scheme" when determining if a pathname should be treated as opaque.The new logic recognizes that any pathname starting with
/
is hierarchical and should not be treated as opaque, regardless of the protocol.Fixes denoland/deno#29935
🤖 Generated with Claude Code