should we provide pattern matching against hostnames?

[wanderview]

At the TPAC 2020 discussion @annevk raised the question that the use cases for hostname pattern matching are not well documented. Also, path-to-regexp does not have broad usage for hostname matching like it does for pathnames.

So far the hostname matching use cases are:

• FetchEvent handling that needs to execute different logic based on the origin of the request; e.g *.my.cdn.com, etc. This is based on discussing workbox use cases with @jeffposnick.
• Web platform features other than service workers that need to match against hostname. CSP is a legacy API that does this. @jeremyroman is working on a new API feature that needs this and was hoping to use URLPattern.

So far, however, it does not sound like these use cases need my proposed "suffix behavior" where . is treated as a suffix character that is grouped with optional and repeating groups. Since this is an addition to path-to-regexp, it probably makes sense just to remove this feature for now. Instead, hostname would support "simple" patterns without any special prefix or suffix behavior.

Based on all that I plan to at least prototype the full URLPattern including hostname matching. This will not require that much extra work if I only expose the "simple matching" approach without prefix/suffix behavior. Once developers can play with the API and give feedback we can decide whether to keep or remove it.

Let's use this issue to track use cases and feedback around the feature.

[wanderview]

I have this working in the prototype and it seems to work well. I'm inclined to keep it.

[wanderview]

This has been codified in the spec.