Possible to set a relative path on pathname?

[pmeenan]

We're working on the compression dictionary spec which has a need for URL pattern matching but only the pathname and search are configurable since the patters enforces same-origin requirements.

Is there a way to provide relative paths to a given URL on the object constructor or is it cleaner to just use the URLPattern(pattern, baseURL) format, specify that the baseUrl will be the URL of the request and pattern can then be relative or absolute and we just enforce the same-origin requirements out-of-band?

[wanderview]

Not sure I fully understand, but there is the new URLPattern({ pathname: var, baseURL: myBase }). Is that what you are looking for?

[pmeenan]

I guess so. It wasn't clear from the MDN docs if baseURL could be used in the object-based constructor but I see the spec actually accounts for it, thanks.

[wanderview]

Note, for browser integrations you could also use just URLPattern component internal details directly. For example, my old service worker plan was to have only pathname strings and I just internally was going to set the baseURL directly based on SW semantics.

[pmeenan]

Just hoping to also offload a lot of the spec on how the matching is done and point to URLPattern for the implementation details. I expect most of the push-back for our use case is going to come from non-browser clients having to implement the pattern patching.

[wanderview]

FWIW, there are two other implementations. A js polyfill and a rust implementation in deno.

[domenic]

Assuming you are taking a string as an input (and not, e.g., a JS object or equivalent), I think there are two paths:

• The string is the pathname, and the resulting URLPattern is as if via new URLPattern({ pathname: input, baseURL: myBase }). (Note that this has a footgun per Base URL inheritance gives unintuitive results #179 of inheriting the search from the base URL, but we are working to fix that.)

• The string is a URL pattern string, and the resulting URLPattern is as if via new URLPattern(input, myBase). You then would enforce the same-origin requirements out of bound, indeed.

The latter feels better to me, personally. It is the direction we've steered for service worker static routes, which were originally more like the former.

The latter is also the only natural way to let you have patterns that include any search matches, I think. Although URLPattern isn't great for search matching (see #150), it still seems like something like /my-path?foo=bar&baz=* might be worth supporting.

On the other hand, @wanderview seemed to be advocating for something more like the former in #20, and apparently that stemmed from a suggestion by @annevk.

[annevk]

I guess I'm not entirely sure what options we have. It would seem kinda nice if we can constrain input to actually be a path (potentially with query?) and not any kind of pattern that when same-origin we only use the path of. That would also reduce the complexity for implementations only caring about path-matching.

But using the same underlying primitive for path-matching across specification is even more important.

[jeremyroman]

My preference is also the latter. If the author chooses to supply a pattern that cannot match in your use case (because it would only match cross-origin URLs, or would require the presence of a fragment), then we can simply discard it and consider showing a warning message in developer tools. I don't think it's very likely that anyone would actually write Use-As-Dictionary: match="https://another.site/*", but if they do we can just tell them they've done something silly (and it would be ill-formed regardless of what option we decide).

[jeremyroman]

Put another way, I'd prefer to subset the URL pattern syntax in in as obvious a way as possible. Ideally a way so obvious that we're excluding only the patterns that couldn't match anyway.

[domenic]

I opened a slightly more-general issue here: #182