#87 closed defect (invalid)
location core module and case sensitive matching
Reported by: | Michał L | Owned by: | somebody |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | nginx-core | Version: | 1.0.x |
Keywords: | location, case sensitive | Cc: | |
uname -a: | Microsoft Windows XP [Wersja 5.1.2600] SP3 | ||
nginx -V: |
nginx version: nginx/1.0.11
TLS SNI support enabled configure arguments: --with-cc=cl --builddir=objs.msvc8 --with-debug --prefix= - -conf-path=conf/nginx.conf --pid-path=logs/nginx.pid --http-log-path=logs/access .log --error-log-path=logs/error.log --sbin-path=nginx.exe --http-client-body-te mp-path=temp/client_body_temp --http-proxy-temp-path=temp/proxy_temp --http-fast cgi-temp-path=temp/fastcgi_temp --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs .msvc8/lib/pcre-8.12 --with-zlib=objs.msvc8/lib/zlib-1.2.5 --with-select_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --w ith-http_dav_module --with-http_stub_status_module --with-http_flv_module --with -http_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-mail --with-openssl=objs.msvc8/lib/openssl -0.9.8r --with-openssl-opt=enable-tlsext --with-http_ssl_module --with-mail_ssl_ module --with-ipv6 |
Description
Hello,
I think I found a problem with respecting case sensitive setting at location, here is my test config:
server { server_name test.localhost; root d:/public; location ~ /ePr { proxy_pass http://192.168.0.2:8080; } }
Requests like this one below goes to proxy, according to documentation this is wrong or I miss something.
/epr/Extensions.js"
Change History (5)
comment:1 by , 13 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 13 years ago
Well that's really not what I would expect from http server, but if You say so. Gettin back to apache.
follow-up: 4 comment:3 by , 13 years ago
Using case-sensitive matching matching by default will likely result in problems (including security ones) due to filesystem itself being case-insensitive. This probably needs to be better documented, but at least wiki mentions it.
If you need case-sensitive regexp match under Windows, you may unset the "i" option in regular expression:
location ~ "(?-i)/ePr" { ... }
follow-up: 5 comment:4 by , 13 years ago
Replying to Maxim Dounin:
Using case-sensitive matching matching by default will likely result in problems (including security ones) due to filesystem itself being case-insensitive. This probably needs to be better documented, but at least wiki mentions it.
If default setting is case-insensitive there is no risk (IMHO). As a conscious user, Im looking at docs ok, I have an option so I'm setting it but it dosen't work like I would expect to.
Wiki says:
For case-insensitive operating systems, like Mac OS X or Windows with Cygwin, literal >string matching is done in a case insensitive way (0.7.7). However, comparison is limited >to single-byte locale's only.
There is no mentions about case sensitive setting and its dependency on system.
If you need case-sensitive regexp match under Windows, you may unset the "i" option in regular expression:
location ~ "(?-i)/ePr" { ... }
Thanks for Your feedback.
comment:5 by , 13 years ago
Replying to Michał L:
If default setting is case-insensitive there is no risk (IMHO). As a conscious user, Im looking at docs ok, I have an option so I'm setting it but it dosen't work like I would expect to.
It looks like you are under the impression that the "~" means case-sensitive matching. It's not. The "~" means "regexp matching", and "~*" means caseless regexp matching (essentially the same under Windows). The only way to get case-insensitive matching under Windows (and other case-insensitive platforms) is to use embedded regular expression options as outlined above.
It is expected behaviour on Windows. Location matching in the case-insensitive operating systems always performs in a case-insensitive way.