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-bounces@nginx.org on behalf of francis@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 francis@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