Skip to content

fix: redefine opaque pathname detection for custom protocols #62

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

hirochachacha
Copy link

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:

    • Protocol is empty, OR
    • Protocol is a special scheme (http, https, ws, wss, ftp, file), OR
    • Pathname has a leading '/' (indicating hierarchical path)
  • Updated both process_pathname_init and the pathname compilation logic to use consistent criteria

Test Plan

  • Added comprehensive test case issue61 that verifies:
    • myhttp://example.com/:directory/:file → pathname: /:directory/:file (not escaped)
    • myfile:///test → pathname: /test (not escaped)
  • All existing tests pass
  • Verified the fix resolves the original issue where pattern syntax was incorrectly 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

@CLAassistant
Copy link

CLAassistant commented Jun 28, 2025

CLA assistant check
All committers have signed the CLA.

@hirochachacha hirochachacha force-pushed the fix-opaque-pathname-detection branch 3 times, most recently from 823d18b to 7b5f068 Compare June 28, 2025 11:10
…d#61)

Changes opaque pathname detection logic to treat pathnames as non-opaque when:
- Protocol is empty
- Protocol is a special scheme (http, https, ws, wss, ftp, file)
- Pathname has a leading '/' (indicating hierarchical path)

This fixes issue denoland#61 (denoland/deno#29935) where custom protocols like myprotocol://example.com/:directory/:file
were incorrectly escaping pattern syntax in pathnames.

Fixes denoland#61
@hirochachacha hirochachacha force-pushed the fix-opaque-pathname-detection branch from 7b5f068 to edbcb38 Compare June 28, 2025 11:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

URLPattern cannot parse "myprotocol://example.com/:directory/:file"
2 participants