Should pattern matching be case sensitive or insensitive?

[wanderview]

By default path-to-regexp matches using a case-insensitive mode.

Currently URLPattern uses case-sensitive matching instead. This was chosen because most URL components are case sensitive at it seems important to be able to distinguish between URLs that the server may handle differently. The hostname passed to test() and exec(), however, is normalized to be lower case, so pattern matching hostnames is effectively case-insensitive.

We could offer an option to enable case-insensitive matching, but it would be nice not to have these kinds of options in the API if we can avoid it.

What do you think? Do we need a case-insensitive mode?

(Note, this is also discussed in #28, but we would like to collect community feedback in the discussion and then summarize in the issue.)

[Sayan751]

I think this would be a valuable addition. And considering the Regex patterns are supported in a large extent for pathname and search, expecting case-insensitive match won't be that far-fetched, wrt. Regex flags.

Also, to support case-insensitive match in user-land would be a bit troublesome in the present state of the proposal. For example, to support case-insensitive match for the path ab, I need to have four URLPatterns with following pathnames: ab, AB, aB, Ab; that is for a pathname of length n I need to check 2^n patterns in worst case. Now think about if the pattern supports both pathname and search matching, then the worst case estimation would be 2^n X 2^m where n is the pathname length and m is the search length.

Another memory-friendly way would be to register something like this: { pathname: '/([hH][oO][mM][eE])' } to support case-insenitive matches for /home. However, this returns a match in the pathname.groups.0 when execed. I am not sure how to have non-cpaturing group for this. I have tried { pathname: '/(?:([hH][oO][mM][eE]))' }, but it throws error:

Failed to construct 'URLPattern': Invalid pathname pattern '/(?:[hH][oO][mM][eE])'. Regex cannot start with '?' at index 2

Considering the hairy situations that may arise, I think it might be best to support a flag to enable case-insenitive matches. Broadly speaking, it will be synonymous to specifying the case-insensitive flag for regex; for example: /\/home/i.