How to serve static files in case insensitive nginx?
I'm trying to use static files with nginx and I've already tried adding a parameter ~*
to the location parameter, but it doesn't seem to work with what I'm trying to do: serve files with the -insensitivity case. Right now, I am getting a 404 if the url case does not match the filename on the filesystem.
For example, I have a file /usr/share/nginx/psimages/scripts/ajaxprogress.js
and I can access it by going to the URL /scripts/ajaxprogress.js
, but I also need to access it by going to /scripts/ajaxprogress.js
, which is currently giving me a 404 error when I try to download it.
Here's my config:
server {
error_log /var/log/nginx/ngerror.log debug;
listen 80 default_server;
listen [::]:80 default_server;
root /usr/share/nginx/psimages;
index index.html index.htm;
# Make site accessible from http://localhost/
server_name localhost;
location ~* / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
# Uncomment to enable naxsi on this location
# include /etc/nginx/naxsi.rules
# Wide-open CORS config for nginx
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
#
# Om nom nom cookies
#
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
#
# Custom headers and headers various browsers *should* be OK with but aren't
#
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
#
# Tell client that this pre-flight info is valid for 20 days
#
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Content-Length' 0;
return 204;
}
if ($request_method = 'POST') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
}
if ($request_method = 'GET') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
}
}
}
source to share
From the authoritative World Wide Web Consortium specifications for URLs:
In general, URLs are case sensitive (with the exception of hostnames). There may be URLs or portions of URLs where the case is irrelevant, but identifying them can be tricky. Users should always keep in mind that URLs are case sensitive.
The machine name is released because the Domain Name System has long, previously defined case-insensitive names in section 2.3.1.
Lack of an extremely compelling excuse, you MUST NOT violate the w3.org specifications as you never know what side effects it might generate.
As an example, using case-sensitive URLs can confuse caching proxies that cannot distinguish between ThisFile.html
and ThisFile.html
(or 144 code variants for that name). Since, by definition, you can never know if you hit a caching proxy or how many of them, chances are that it will lead to the wrong document.
source to share
This cannot be done with nginx stock.
I think the idea is that you know better what your file names are. A case-insensitive file search requires reading and traversing the entire directory structure (for example readdir(3)
), comparing each file entry against the input. Imagine there were 1k files in the directory; this results in doing a case insensitive comparison on average with half of those 1k files, which would be extremely inefficient for a single query of what a static file meant (repeat and multiply if the directories themselves are to be case insensitive). Compare this to a single call open(2)
where the file (with its correct case and path) is already known.
As such, it would likely be wiser to enforce the static files case than suffer such a dramatic performance hit (and the added complications of having to have some kind of caches for release). If, on the other hand, you don't need performance to serve static content, you can also proxy your static requests to another server that supports / encourages such inefficient performance.
source to share