Should pathname patterns automatically match an optional trailing /?

[wanderview]

By default path-to-regexp operates in a "non-strict" mode. This means that a trailing / is always allowed at the end of the input. For example, if the pattern is /foo/bar it will also match /foo/bar/ automatically.

URLPattern currently uses "strict" mode, however. This means that /foo/bar does not match /foo/bar/. This was chosen since it seems important to be able to target input without a trailing slash which is impossible in non-strict mode. In addition, the developer can easily opt-in to the non-strict behavior by appending {/}? to the end of their pattern. So in our example they would use /foo/bar{/}?.

What do you think?

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

[kettanaito]

Hey, @wanderview. Thank you for an open opportunity to discuss URLPattern.

When it comes to trailing slashes, I believe that developers expect them to be optional. Such expectation comes from the way various libraries and frameworks handle trailing slashes and should be taken into account when designing the URLPattern behavior.

I took the liberty of analyzing how some of the major server-side frameworks handle trailing slashes. I haven't found a framework that would be sensitive to trailing slashes.

Frameworks I've tested:

• Koa
• Sails
• Express
• path-to-regexp (a library but powers countless URL matching solutions)

Ambiguity

The question itself is rather tricky, as /foo and /foo/ are two different URLs that may point at different resources. Given that this ambiguity has a place to be but is rather archaic (and the solutions above prove that), I'd say that treating trailing slashes as optional is a good default. It's much more common to meet this behavior on the web than when the trailing slash is required. The latter should be an explicit intention that has a respective API on the URLPattern side.

[wanderview]

Please see issue #14 where we already came to a decision on this topic. Unfortunately there does not seem to be a way to close github discussions.

In the end we chose not to default to optional trailing slashes. The rationale is:

1. Getting an optional trailing slash is as easy as adding {/}? to the end of your pattern.
2. If the default is to match an optional trailing slash there is no way to opt-out of the behavior in the pattern syntax in order to match precise endings.
3. We want to support URLPattern in web platform APIs where the difference between intended URLs may be more significant. We greatly prefer precise definitions for web API inputs.

[kettanaito]

My bad, I should've checked the issue first.

I agree that making an optional slash is more straightforward 👍 Thank you for sharing the detailed motivation.

[timonson]

In the end we chose not to default to optional trailing slashes.

@wanderview just to clarify, the described behavior does not count for URLs which have no pathname or where the pathname only contains a /. E.g. https://example.com and https://example.com/. Here new URLPattern({ pathname: "/" }) defaults to an optional trailing slash, right? Would you mind elaborating why you chose this exception? Thank you!

[karwa]

https://example.com and https://example.com/ are considered identical by the URL Standard.

(But only for http(s), ws(s), ftp, and file URLs. For other URL schemes, they are interpreted as being possibly distinct locations)

[ntotten]

We have built a standards-based API Gateway at Zuplo and use URLPattern as our route matcher. FWIW, this issue of not allowing a non-strict mode matcher with optional trailing common comes up A LOT with customers. Almost every customer of ours expects paths to match with optional trailing slashes.

For now, we instruct people to follow the spec and modify the regex, but this doesn't seem like a long-term solution for us (it's just not a good developer experience).

I would really prefer an option on URL Pattern that allows for non-strict matching that allows optional trailing slash matching.