should URLPattern be case sensitive or insensitive

[wanderview]

The path-to-regexp library is case insensitive by default with an option sensitive:true to override. In contrast, most components of a URL are case sensitive with the hostname being the only case insensitive part.

What should URLPattern default to and should it provide an option to override?

We could follow path-to-regexp as our cowpath as to what is popular/expected and make all components case insensitive by default. We would then likely need to provide an option to require case sensitivity since it will matter in some URLs.

I believe @domenic advocates that we by default match URL behavior. We might need to provide an override option to always be case insensitive.

[jeremyroman]

FWIW I've always assumed URLs to be case sensitive and it would have been surprising to me for this to be case-insensitive.

Depending how patterns are used, this could have security implications (both ways). For instance, a site which allows user profiles under / might allow requests to known URLs, and inadvertently also authorize requests to results which are a case-insensitive match.

Also, case sensitivity is somewhat tricky in the presence of non-ASCII characters, which would be URL-escaped and a naive case conversion algorithm wouldn't account for. (On the other hand, doing full Unicode case folding is a huge can of worms you definitely do not want to open.)

[annevk]

What kind of case-insensitive? (Also, this feels a lot like #23 in what a solution might look like.)

[wanderview]

Are there different kinds of case-insensitive? For path-to-regexp it uses the RegExp i flag to ignore case. Like /foo/i.

To be clear, I think hostname always needs to be case-insensitive. So we're really talking about what to do with the rest of the URL components.

[annevk]

Yeah, there's just ASCII and then there's various kinds of Unicode. And hostname doesn't need to be case-insensitve as the URL parser will normalize it. So if this does the same as the parser you can just compare for equality (which I think is what we want).

[wanderview]

Good to know URL normalizes the hostname. If we do the idea in #27 I think we would have to do the hostname normalization ourselves in that one case.

[wanderview]

Note, I opened a github "discussion" to collect community feedback on this issue. See #39.

[wanderview]

The prototype is case-sensitive and so far I think that is working well. I'm going to mark this decided for now.

[wanderview]

This is now codified in the spec.