Skip to content
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

"Hostname pattern is an IPv6 address" called with null #209

Closed
rubycon opened this issue Jan 19, 2024 · 1 comment · Fixed by #214
Closed

"Hostname pattern is an IPv6 address" called with null #209

rubycon opened this issue Jan 19, 2024 · 1 comment · Fixed by #214

Comments

@rubycon
Copy link
Contributor

rubycon commented Jan 19, 2024

What is the issue with the URL Pattern Standard?

The hostname pattern is an IPv6 address steps except a pattern string but in the initialize steps it can directly be called with null when hostname isn't present in the argument passed to the constructor :

  1. If the result running hostname pattern is an IPv6 address given processedInit["hostname"] is true, then...

The hostname pattern is an IPv6 address steps then fail to check its null input code point length:

  1. If input’s code point length is less than 2, then return false.

This issue is related the null default value issue discussed here

@rubycon rubycon changed the title *Hostname pattern is an IPv6 address* called with null "Hostname pattern is an IPv6 address" called with null Jan 19, 2024
@jeremyroman
Copy link
Collaborator

Yes, this algorithm assumes that getting the value of a map returns null for absent entries, but that's not what map/get does (it asserts that the entry is present). Let me see what the simplest way to fix that is.

jeremyroman added a commit that referenced this issue Jan 30, 2024
Currently, some steps in "initialize a URLPattern" access potentially nonexistent entries in the processedInit map, and expect "compile a component" to receive these as null, even though it requires a string.

Instead, these entries are now always populated after calling "process a URLPatternInit" so that subsequent steps can depend on a valid string.

Since the comparison with the default port requires that the two types be the same, fix that too.

Fixes #209.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants