Interestingly, this will teach me not to leave out "irrelevant" bits of my config files when posting them. My configs failed to include a few items like ModSecurity, because it didn't occur to me that they could have any impact on the problem I was describing. As it turns out, disabling ModSecurity solved the problem. I'm still not sure why ModSecurity is causing NGINX to serve bad databy brih - Nginx Mailing List - English
So now it doesn't look like it's a caching issue at all. I've completely gutted my config files and stripped it down, and I'm still seeing the same issue. I even shot a video of what I'm seeing and stuck it on YouTube as an example (http://youtu.be/lPR1453YBUw). As the video shows, the connections for the linked images don't load properly on reloads if I'm connecting through the NGINX server, butby brih - Nginx Mailing List - English
I'm having an odd issue, and I'm not sure where to start. We've been implementing a number of NGINX servers recently, and one of them is doing a proxy_pass to an older IIS7 server that we'll be phasing out soon, which is hosting a couple of minor sites in our datacenter. When initially browsing the site, everything appears to be working properly.. But in most browsers, if you hit reload a coupleby brih - Nginx Mailing List - English
Are there any performance implications associated with having a large number of static prefix locations? We really are looking at having hundreds of location blocks per server if we use static prefixes, and my primary concern up until now has been maintainability. If I eliminate maintainability as a concern, the next question that comes up is performance. How much of a performance hit (if any) wilby brih - Nginx Mailing List - English
So there is no precedence given to nested regex locations at all? What value does nesting provide then? This seems like it should be a fairly simple thing to do. Image/CSS requests to some folders get handled one way, and image/CSS requests to all other folders get handled another way. This is an experimental pilot project for a datacenter conversion, and the use of regex to specify both the fileby brih - Nginx Mailing List - English
So it sounds like my only solution is to restructure the locations to avoid the original match in /. I don't have access to the servers again until tomorrow, but I'm wondering if something like this would work: location / { #base content } location ~ regex2 { #alternate folders to proxy_pass from .Net servers } location ~ regex3 { #catch all css, js, images, andby brih - Nginx Mailing List - English
Close, it's more akin to: location / { location ~ regex1 { # regex inside / } } location ~ regex2 { location ~ regex3 { # regex inside regex2 } } And the question is: where will a request matching both regex1 and regex3 be handled? Regex 1 & 3 look for the same file types and are identical, but contain different configby brih - Nginx Mailing List - English
Hello, we are using NGINX to serve a combination of local and proxied content coming from both an Apache server (mostly PHP content) and IIS 7.5 (a handful of third party .Net applications). The proxy is working properly for the pages themselves, but we wanted set up a separate location block for the "static" files (js, images, etc) to use different caching rules. In theory, each of theby brih - Nginx Mailing List - English
I'm trying to create a second location in NGINX that will only fire for a specific file type. Specifically, I have NGINX acting as a proxy for a server that primarily serves PHP files. There are, however, a bunch of folders that also have ASPX files (more than 120), and I need to use a different configuration when serving them (different caching rules, different Modsecurity/NAXSI rules, etc). Nby brih - Nginx Mailing List - English