Thank you, this was incredibly useful and helped me think this through in Nginx terms and I have everything working now. Thank you again!
Minor side question, is there a variable I can use to post to a debug header to indicate if a page was newly written to the cache versus a page that was read from cache? If I had this information, then from a tier2/3 support side it could speed up debugging. ___________________________________________ Michael Friscia Office of Communications Yale School of Medicine (203) 737-7932 - office (203) 931-5381 - mobile http://web.yale.edu <http://web.yale.edu/> On 2/16/18, 7:35 AM, "nginx on behalf of Francis Daly" <nginx-boun...@nginx.org on behalf of fran...@daoine.org> wrote: On Thu, Feb 15, 2018 at 01:22:04PM +0000, Friscia, Michael wrote: Hi there, > To add one more thing. I mentioned that my testing failed. Exactly what was failing is that the map{} block that worked and then stopped working was the problem, the $nocache variable would always return the default value no matter what I did. there is a lot of information here, and your design seems quite complex. I think that you are close to having an nginx config that does what you want; but I suspect that it will help you to have a clear picture of how things are intended to work within nginx, so that you understand the building blocks available to you, so that you can put them together in the way that you want. Very briefly and hand-wavily (and check the proper documentation to fill in all the pieces I am leaving out): In your common case, a request comes to nginx; it is handled in one server{} in one location{}, which does proxy_pass to an upstream http server. nginx checks the proxy_cache_key corresponding to the request, and if that key is in the proxy_cache, then the content is returned from there directly. If that key is not in the proxy_cache, then the request is made to upstream, the response is written to the proxy_cache, and the response is also returned to the client. Not everything is cached from upstream. There are http rules for when things can and cannot be cached, and for how long they can be cached, and nginx (in general) obeys them. So: the simplest thing on the nginx side is for your upstream http server to use http rules to say "this response is not cacheable", and nginx will deal with it without extra config on your part. If you want nginx not to look in the proxy_cache for the proxy_cache_key for this request, you can use proxy_cache_bypass. If you want nginx not to write the response from upstream into the proxy_cache, you can use proxy_no_cache. "map" is defined outside all server{}s, and takes the form "map current$thing $new_variable {}". $new_variable gets a value the first time it is used in this request -- if $new_variable is not used, the map is never consulted; so having multiple "map"s that are not used by this request has zero overhead for this request. And: unless you understand it, don't use "if", especially not inside a location{}. If you want to, for example, add a debug-response-header with a certain value, do exactly that. Do not try to do "if the value is non-zero, add the header; else don't add the header". Just add the header with the value, or with a concatenated set of values, and let the reading side decide how to interpret it. So: putting all that back in to what you seem to want to do... * do use a map to read $upstream_http_x_secured_page and to set $your_variable to non-blank and non-zero only when the $upstream_ variable is true * do use a proxy_no_cache which includes $your_variable * do not read $your_variable anywhere early -- such as in a proxy_cache_bypass directive, or anywhere within an if() block -- because it is unnecessary, and it will break things * do make sure your proxy_cache is empty of things that you now newly want to "proxy_no_cache", before you start And if you have any behaviour you do not want or do not understand, it is very helpful if you can show the exact config that shows that behaviour, so that someone else can reproduce it without having to guess what you might have meant. Ideally, a test config will have a few tens of lines, with most of the unnecessary parts removed and with all of the private details replaced with information that was tested and works on something like "localhost". copy-paste is better than re-type. Good luck with it, f -- Francis Daly fran...@daoine.org _______________________________________________ nginx mailing list nginx@nginx.org https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.nginx.org_mailman_listinfo_nginx&d=DwICAg&c=cjytLXgP8ixuoHflwc-poQ&r=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs&m=a54DkMNy8szWJBw16l-IByb_d7_KsXWo75h2opft0C0&s=MAdD_ml0ZQjhTod2iWoNxS4zKvzsZt2nw2l1N4uTGfk&e= _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
