Hi Maxim, Thank You for your answer. It really makes sense, however, in the mentioned case, I could see an elevation of the number of occurrences just after the migration from nginx 1.6 to nginx 1.8. This behaviour affects < 0.2 % of our requests, but it means hundreds of requests per hour. Also, I could see this implementation isn't new, therefore I believe this behaviourby biazus - Nginx Mailing List - English
Hey Guys, I've been using nginx 1.8.0 for a couple of months, and I noticed a critical message at error log informing that "cache file has too long header". 2015/09/10 17:11:03 27245#0: *10686 cache file "/data/smallfiles/http/6/d8/f5df8d6eda60819319688d1bc0cb2d86" has too long header However, as you can see at the example bellow, there is nothing abnormal with the fby biazus - Nginx Mailing List - English
Please try to remove $ in the end of the expression: something like this: location ~ .*\.(js|css) { expires 7d; } Also, make sure you are using args in the cache key: proxy_cache_key "$host$uri$is_args$args"; Regards, Biazusby biazus - Nginx Mailing List - English
Yes, they do recicle, but it will depends how the keep alive timeout is configured in the backend. I believe there is a similar topic here: http://forum.nginx.org/read.php?2,249924,249953 Regards, Biazusby biazus - Nginx Mailing List - English
Hi, You may check dynamic upstream module: https://github.com/GUI/nginx-upstream-dyanmic-servers Alternatives: http://www.senginx.org/en/index.php/Dynamic_DNS_Resolve http://openresty.org/ Regards, Biazusby biazus - Nginx Mailing List - English
Please try something like that: proxy_redirect http://$proxy_host/ $scheme://$host/; Regards, Biazusby biazus - Nginx Mailing List - English
Hi Guys, We have developed a "cache migration tool" in order to keep the cache compatibility between Nginx 1.6.x and 1.8.x. Comments and suggestions are welcome! https://github.com/acaciocenteno/ngx_scripts Thanks, Biazusby biazus - Nginx Mailing List - English
Config files seems to be OK. Just make sure "ssl_trusted_certificate" contais the intermediate & root certificates (in that order from top to bottom). You can test with the following command: echo QUIT | openssl s_client -connect yourhost.com:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update' good luckby biazus - Nginx Mailing List - English
I have been using Nginx 1.8.X with ocsp stabling for a couple of weeks and it seems to be fine. Please send your config files, it may help...by biazus - Nginx Mailing List - English
Hey Guys, We have been testing Nginx 1.8.x, and We realize that the cache structure for Nginx 1.8.x is not compatible for Nginx 1.6.x. In other words, by updating Nginx 1.6.x to 1.8.x, all the cache objects will be revalidated. We are working in a tool to migrate 1.6.x cache objects to 1.8.x in order to avoid any cache strike, but We have been having hard time to do that. Do you guys kby biazus - Nginx Mailing List - English
I got it! The "issue" was the origin server sending "Vary: Accept" header. In order to avoid this behaviour, simply set "proxy_ignore_headers Vary;" Thanks!by biazus - Nginx Mailing List - English
Hi Guys, I noticed that Nginx 1.8.X is taking into account the Client Header "Accept" for versioning the cache objects, for instance: This request, generates one object in cache: curl -sv -o /dev/null 'http://www.foo.bar/image.png -H 'Accept: */*' And this, generates another one: curl -sv -o /dev/null 'http://www.foo.bar/image.png -H 'Accept: text/html, image/gif, imageby biazus - Nginx Mailing List - English
Hey Guys, We have been using the latest stable Nginx version 1.6.1, and I've could notice that we might be facing a bug that was supposed to be fixed in version 1.5.11. Bugfix: the $upstream_status variable might contain wrong data if the "proxy_cache_use_stale" or "proxy_cache_revalidate" directives were used. On MISS requests the variables "$upstream_status&quoby biazus - Nginx Mailing List - English
Sorry Guys, my bad! The correct directive for /img path is: location ^~ /img/ { proxy_pass http://foo.bar.com/; break; } That way works as expected! Best Regards, Biazusby biazus - Migration from Other Servers
Hi Everyone, I've been facing a little situation using proxy_pass. As you can see at conf file bellow, there is a docroot filesystem where the static files are located, and a proxy_pass configuration for another path. It works fine, however when i configure the expires directives, i got 404 for the proxy_pass requests. server { server_name foo; root /nfs/staticfiles/;by biazus - Migration from Other Servers