Support more generic URLPattern such as scheme, host, origin, etc

[shhnjk]

Support more generic URLPattern such as scheme, host, origin, etc

[wanderview]

By the way, thank you for bringing this use case to my attention. There was some discussion at TPAC about limiting the effort to only pathname for now. I plan to try to press forward with the full proposal, though.

[wanderview]

FWIW there is an existing polyfill written on top of path-to-regexp: https://github.com/kenchris/urlpattern-polyfill/blob/main/src/index.js

I expect the final URLPattern will look at a bit different (targeting newer path-to-regexp now, etc), but its possible to do all this server-side already more or less.

[wanderview]

The current design does support patterns for each URL component. So your first example could be expressed as:

new URLPattern({ protocol: 'https' });

Currently the design is focused on the more granular URL components and does not have an "origin" concept. You could implement your second example like:

new URLPattern({ protocol: 'https', hostname: 'example.com' });

Or by providing a "base URL" and overriding the pathname part to be a wildcard:

new URLPattern({ baseUrl: "https://example.com", pathname: "/*" });

Maybe we can add some kind of origin short hand, but I'd like to get the basics prototyped first.

Does this meet your use cases?

[shhnjk]

Yeah, this should meet the requirement! Thanks!

[shhnjk]

No problem :) I also heard feedback from people that this will be useful in server-side as well to check request URL pattern, so some people are looking forward to use this in server-side Node JS 😀

[jeremyroman]

The current design does support patterns for each URL component. So your first example could be expressed as:

new URLPattern({ protocol: 'https' });

Currently the design is focused on the more granular URL components and does not have an "origin" concept. You could implement your second example like:

new URLPattern({ protocol: 'https', hostname: 'example.com' });

nit: If I understand correctly this will permit https://example.com:PORT for every port, which is broader than the origin https://example.com (which is only port 443). Just mentioning this because it seems like a potential pitfall.

[wanderview]

nit: If I understand correctly this will permit https://example.com:PORT for every port, which is broader than the origin https://example.com (which is only port 443). Just mentioning this because it seems like a potential pitfall.

That is currently correct. You would need to be more restrictive by including port: '(443)?' if the port restriction was important.

We might want to make some "empty string matches the default port for the port" type equivalence, but I'm a bit leery of making one of the components an exception to the "gets a wildcard by default" rule.

[wanderview]

I wrote a couple related issue:

#32
#31