Resolved Nginx serve static files list should be case insensitive?

[G J Piper]

The setting "Serve static files directly by nginx" allows you to list all the file extensions that will be handled by nginx directly. It creates case-sensitive location block(s) in the settings file, like so:

location ~ ^/(.*\.(ac3|etc|etc|etc|zip))$ {
try_files $uri @fallback;
}

Shouldn't it be like the following, so that it can be case insensitive and reduce the number of file extension permutations we need to include in the field? --

location ~* ^/(.*\.(ac3|etc|etc|etc|zip))$ {
try_files $uri @fallback;
}

Or is it designed so we must enter every conceivable case of every file extension in the field? Is there some reason why someone would want a certain case of file ext to be served but not it's counterpart?

 

[UFHH01]

Hi G J Piper,

Or is it designed so we must enter every conceivable case of every file extension in the field?

It IS exactly the reason, that ONLY files, which are explizit defined, will be served as static files, why the location definition does not include additional file-extension, than the ones that we define.

 

[G J Piper]

Ok. So for example, JPG, Jpg, jPg, JPg, JpG, jpg, JPEG, Jpeg, JPeg, jPeg, jpeg, etc, ETC, ETc... just to get all the possible customer extensions for one image type? (and do this with the other few dozen types as well?)

Maybe it would be better to have a checkbox to signify insensitive if desired?

 

[UFHH01]

Hi G J Piper,

sorry, but your examples are not really practical. You should always tell your customers, that file-names and their extensions ( just like all other "system specific names and extensions" ) are expected to be LOWER CASE on linux systems and the customer should be aware, that case-sensitive matters, when it comes to issues/errors/problems. There is absolutely no need to define all possible spellings for an extension.