URLPattern

[wanderview]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: URLPattern
• Specification or proposal URL: https://wicg.github.io/urlpattern/
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @annevk and @asutherland were involved in previous discussions.

Other information

Previously discussed as part of service worker scope pattern matching at:

• TPAC 2019
• TPAC 2020 Video Call

We also have some web developer feedback that may be helpful.

Thanks.

[wanderview]

FYI, there is now an intent-to-ship for this feature in chromium.

[annevk]

Is there a fully conforming implementation of this specification? I worry a bit about Chromium's internals leaking due to it not having a compliant URL parser.

I also left some minor comments directly on the repository and asked for feedback in whatwg/url.

@valenting @asutherland did you have a chance to look at this already?

[wanderview]

Is there a fully conforming implementation of this specification? I worry a bit about Chromium's internals leaking due to it not having a compliant URL parser.

The polyfill passes all WPT tests in both chromium and non-chromium environments. It uses new URL() under the hood for canonicalization wherever it can (although there are some cases that are made difficult by URL API).

The deno project is also working on a rust implementation. As second implementer they are catching a lot of the inevitable mistakes in the spec (which we are fixing as reported). I'm not sure how close they are to completion of their implementation.

[asutherland]

@annevk I have not been following the evolution of the spec text proper but have been following the issues and discussion since the initial explainer.

URLPattern has a clear use case and it was appropriate for it to be split out into its own spec independent of the ServiceWorkers spec proper to be used as a future primitive for ServiceWorkers to build on.

It makes sense to me to mark the spec as worth prototyping.

[lucacasonato]

@annevk Our (Deno) implementation is now complete. There were a few "chromiumisms" in the spec, but they have been all ironed out now. We pass all WPT test cases now.

We managed to implement the entire thing on-top of rust-url's public API (which is more compliant than Chromium's URL parser), so it is implementable on top of other URL parsers.

The implementation is written in Rust, so a bunch of the code could just be reused for Gecko, by pulling in the crate. I'd be happy to collaborate on this front if there is interest - just reach out.

[annevk]

I looked through the tests and I didn't immediately see any for the problematic cases I know about, such as non-special schemes and hosts or relative paths, input such as %6A not getting decoded, etc. I guess that's why the polyfill manages to pass all the tests? I think we should add those those tests. If the polyfill is on top of new URL() a more realistic outcome would be that only Safari passes all tests at this point. And perhaps the Deno implementation. (I'm not sure how far along the rust-url implementation is these days.)

Overall though I agree that it looks pretty solid.

[valenting]

Thanks for the info @lucacasonato - I'll take a look at the possibilities for using the crate in Gecko.
I agree with @asutherland that this is worth prototyping

[wanderview]

I looked through the tests and I didn't immediately see any for the problematic cases

I think we should add those those tests

I'm not opposed to adding more tests hitting places where chrome gets URL encoding wrong, etc. I do think fixing URL interop is a separate problem than URLPattern itself, though. I believe @TimothyGu has recently done a bunch of work to move the ball forward on chrome URL interop.

Edit: Also, I want to note that URLPattern purposely does not specify URL encoding and canonicalization itself, but calls out to the URL spec. And its expected that implementations should use the platform's URL encoding as well (whether its right or wrong). This is so code like this works:

let p = new URLPattern({ hostname: 'café.example.com' });
p.test(new URL('https://café.example.com/foo'));

[annevk]

Yeah, I think it's great how it delegates. I just want to make sure we exercise some of the known problems to ensure it holds up.

@asutherland @valenting would either of you want to create a PR for this?

[wanderview]

FWIW, I think I can at least close one interop issue by making chromium's URLPattern throw for more illegal hostname code points. That should at least avoid making it harder to fix that URL interop issue in the future.

Edit: And I'll add WPT for these code points as part of doing this.

[fregante]

Pasting the bugzilla tracking URL:

https://bugzilla.mozilla.org/show_bug.cgi?id=1731418

[karlcow]

Paper trail: WebKit standard Position

[wanderview]

FYI, we are making a small enhancement to URLPattern to add the option to perform case-insensitive matching. This was a web developer community request. Please see:

https://groups.google.com/a/chromium.org/g/blink-dev/c/hNUoDg94-_8/m/-Cnv2qyMAAAJ
whatwg/urlpattern#148

Note, since this is a small change I thought it might be better to comment here instead of creating a new issue. If you would prefer a new issue, please let me know.