Lighttpd

where intuitively it feels to me

Your feelings are not strong technical arguments.

There are many different ways to interpret virtual paths and to map virtual paths (from url-path) to physical paths in the filesystem, or to leave as virtual paths to be interpreted by other backends (e.g. FastCGI) which might or might not perform their own virtual path to physical path mapping.

The answer to the question: "Should /cgi-bin be handled differently than /cgi-bin/?" is up to the admin writing lighttpd.conf.

I'm curious as to why a trailing slash is not desirable in cases like these.

Please ponder why it might matter and why it might not matter, and what the tradeoffs might be for each choice.

Ultimately, if there is not a strong reason for or against one or the other, then it does not matter enough to make changes everywhere and to document why one should always be used instead of the other.

#2898 describes one case where consistency mattered -- both with or both without trailing slash -- with a pair of directives.

The technical reason behind my question is that =~ '^/cgi-bin' matches not only ^/cgi-bin and ^/cgi-bin/ but also, for example, ^/cgi-bin-implementation-demo.py, causing it to be executed as a cgi program.

I used the word "feel" not because the question arised solely out of a feeling, but because I'm not an expert in this and there's probably things that I don't know or have misunderstood.

The trade off here, to the extent that I see, is that in the typical use case where cgi executables are located under the directory cgi-bin/, =~ '^/cgi-bin/' matches exactly that, whereas =~ '^/cgi-bin' matches a lot more, such as the example I gave above. For novice users who may not be super careful (or not realize that there is a reason for care on this particular bit), the default =~ '^/cgi-bin' can create unexpected or even potentially dangerous behaviour.

Of course, it could be argued that the example I gave is not a typical use case, or novice users being careless is not part of the security model, which all has their validity, but I'm curious to know if there's anything I missed in that there's actually any security-related upside for not having that trailing slash?

Thanks again.

The general answer was already given and will not change. I wrote:

There are many different ways to interpret virtual paths and to map virtual paths (from url-path) to physical paths in the filesystem, or to leave as virtual paths to be interpreted by other backends (e.g. FastCGI) which might or might not perform their own virtual path to physical path mapping.

The answer to the question: "Should /cgi-bin be handled differently than /cgi-bin/?" is up to the admin writing lighttpd.conf.

What you seem to be missing is that how virtual paths are handled is more flexible than your specific, narrow use case that you have in mind.

Yes, /cgi-bin might match /cgi-bin/foo.pl or /cgi-bin-something, but in the case of /cgi-bin, /cgi-bin-something is likely to be rarer, though it is theoretically possible.

Take a different example, and keep in mind virtual paths do not necessarily map to the filesystem:

If I am using mod_proxy, do I want to proxy ^/something or ^/something/? What behavior do I want when the url-path is exactly /something? Do I want to redirect to a virtual /something/ or should I proxy /something as-is? Of course, if I am not precise in my config, then /something-else might also be proxied.

I tend to recommend

$HTTP["url"] =^ "/something/" {
    proxy.server = (...)
}
else $HTTP["url"] == "/something" {
    url.redirect = ("" => "/something/${qsa}")
}

However, for the novice users, many who do not demonstrate careful reading comprehension (if they read the docs at all), simpler is often better. Even with less precise configs, novices are not likely to notice the difference between /cgi-bin and /cgi-bin/. Non-novices should configure lighttpd.conf for exactly the behavior that they desire.

Going back to your original post:

While playing around with lighttpd, I noticed that a couple of sample configuration files as well as documentation pages write URL matching rules without a trailing slash where intuitively it feels to me that there should be.

Vague generalization statement is a vague generalization.

If there are specific examples which you think would benefit from having a trailing slash in the specific examples, please point them out.