Encoding for port removes "443" in substrings of patterns

[azaika]

What is the issue with the URL Pattern Standard?

The "canonicalize a port" algorithm (link) performs "basic URL parser" for https://dummy.invalid/ after its port is replaced by the input string, and therefore, the output becomes the empty string if the input is "443", the HTTPS default port, by the step 2.1.3 of "basic URL parser"'s "port state" (link).

This algorithm runs in the middle of the "parse a pattern string" algorithm (link) for substrings of port pattern. As a result, some patterns compile to non-intuitive patterns. For example, new URLPattern({ port: "*443" }) results in the same pattern with new URLPattern({ port: "*" }).

[azaika]

This issue leads to some "fixed" parts having empty string values, which breaks the implicit preconditions imposed on the Part structure (IIUC).

Safari dodges this issue by not using the whole "basic URL parser" but using a dedicated parser for "port" that doesn't have the default-port-elision functionality [src] while I wasn't able to follow if it's a coincidence or not.

Chrome crashed for some patterns due to this issue (reported in https://crbug.com/520829534), but the fix patch was submitted and will be available soon https://crrev.com/c/7924108. The Chrome's fix is to keep using the "basic URL parser", but uses dummy://dummy.invalid/ as the base of the fake URL in "canonicalize a port" algorithm.

[sisidovski]

This seems to be fairly true. It leads unintended results that we should fix.

When constructing new URLPattern({ port: "*443" }), compile a component algorithm runs. In parse a pattern string, "*443" is tokenized:

• * is recognized as a wildcard and converted into the full-wildcard
• The remaining 443 is converted into the fixed value.

Then, call canonicalize a port as an encoding callback. The callback executes creating a dummy URL This instantiates a URL record with the exact input https://dummy.invalid/. Crucially, its scheme is set to https. The callback then runs the basic URL parser on the standalone string "443" using the dummy URL, and overriding the parser start state to port state.

Then, the basic URL parser returns the empty string because the given dummy URL's scheme is "https", and its default port is 443. The dummy URL's port is set to null.

Probably we should update the canonicalize a port algorithm NOT to replace the default port with the empty string in the basic URL parser. To achieve that, probably we should update the dummy URL scheme to non special one in this algorithm. I'll prepare the PR to fix this.