Re: Response Header IF statement problem

[Francis Daly]

On Fri, Feb 16, 2018 at 01:49:59PM +, Friscia, Michael wrote:

Hi there,

> Thank you, this was incredibly useful and helped me think this through in 
> Nginx terms and I have everything working now. Thank you again!

You're welcome.

Good to hear that you have things working the way you want them to.

> 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.

Possibly $upstream_cache_status?

http://nginx.org/r/$upstream_cache_status, or a section in
https://www.nginx.com/blog/nginx-caching-guide/ for more information.

If the seven states of that variable reveals more information than
you want to, you could use a map to turn three values into "it came from
upstream", and four into "it came from cache", and just send that binary
value in the debug header.

Note that that variable is not exactly what you asked for; it might be
close enough for what you want.

f
-- 
Francis Dalyfran...@daoine.org
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Response Header IF statement problem

[Friscia, Michael]

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 
 

On 2/16/18, 7:35 AM, "nginx on behalf of Francis Daly"  wrote:

On Thu, Feb 15, 2018 at 01:22:04PM +, 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 Dalyfran...@daoine.org
___
nginx mailing list
nginx@nginx.org

Re: Response Header IF statement problem

[Francis Daly]

On Thu, Feb 15, 2018 at 01:22:04PM +, 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 Dalyfran...@daoine.org
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Response Header IF statement problem

[Friscia, Michael]

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.

So in a previous post the suggested code was
proxy_no_cache $nocache;

I also included a add_header X-NoCacheValue $nocache;

My initial tests worked well, I saw the new header and the $nocache value that 
was being decided was being passed just fine. But I don’t know if this sort of 
use of the $nocache value was incorrect. I tried this using the IF() block I 
mentioned below as well as eliminating the IF() blocks entirely and handling it 
all within the server{} block to rule out problems with IF() which I am well 
versed in.

___
Michael Friscia
Office of Communications
Yale School of Medicine
(203) 737-7932 - office
(203) 931-5381 - mobile
http://web.yale.edu 
 

On 2/15/18, 8:03 AM, "nginx on behalf of Friscia, Michael" 
 wrote:

Yes, I should have explained the problem up front. I made the wrong 
assumption I was asking a simple question and quickly realized I was getting 
good answers but my approach was likely flawed from the start.



We are using Nginx just as a cache mechanism across many custom DNS names. 
As a result we have many server {} blocks handling a variety of different DNS 
names, vanity URLs and in a few cases SSL redirects. Where possible a single 
server {} block handles a wildcard DNS name but there are reasons we separate 
some of them out. Given the number of DNS entries, I have also created a system 
for creating *.conf files, so I do not use a single conf file for all the 
servers, instead I divide them out into many conf files. For special 
configuration items that are only included sometimes, I use *.inc files with 
the idea being that nginx.conf includes *.conf but does not include *.inc so 
that way I can make my server{} blocks cleaner and put common configurations 
into inc file. The main benefit being that almost all the config files fit on 
the screen without scrolling that much in VIM. 



Within each of these DNS instances we have a mix of login required content. 
We use three different login methods, IP whitelists, local user/password set in 
our CMS and then we use NetID via CAS/Shibboleth. We don’t want any of the 
login pages cached. 



The way we differentiate this relates to the mechanics on the backend of 
the web application. So we created a custom header called X-Secured-Page which 
is either true or false. In the event the value is true, we do not want to 
cache.



To go a step further, I have made use the add_header to set different 
headers for when we cache a page versus when we do not cache a page. The idea 
being that Tier1 support could view these headers to deflect support calls when 
things are working as intended but also to create Jira tickets with the custom 
header content when things do not seem to be working correctly. In addition to 
this, when the secure page is true, I use this setting proxy_pass_header 
Set-Cookie; but when the secured page is false I use this setting: 
proxy_hide_header Set-Cookie; As for why, it is actually the CAS/Shibboleth 
authentication that fails to work without this setting change. I could easily 
just always pass the cookie but I was trying to eliminate any noise I could. We 
have a fairly complicated stack given the Nginx passes most traffic to a server 
cluster that handles URL rewrites and Vanity URLs at a level we did not want to 
approach in Nginx. We may in the future but right now that is off the table 
given the complexity and work that went into the management interfaces used to 
handle the url rewrites the content owners use.



So my thought process started with a test for $http_x_secured_page which 
for obvious reasons would not work because I was failing to distinguish request 
versus response headers and am very new to Nginx.



Using the responses yesterday, I was 99% sure I had a working model nailed 
down. I had a map block that looked like this



Map $upstream_http_x_secured_page $nocache {

default “0”;

“true” “1”;

“false” “2”;

}



Then in my server block I had logic that looks like this



Server{



Location / {

If ($nocache = “1”) { return 418; }

If ($nocache = “2”) { return 419; };

}

}



Then I had a custom location for each, again this was all just to test and 
it worked. I used a combination of cURL and just using the inspector in firefox 
to see the headers and I was consistently getting the correct code from either 
the 418 or 419 block. So I moved 

Re: Response Header IF statement problem

[Friscia, Michael]

Yes, I should have explained the problem up front. I made the wrong assumption 
I was asking a simple question and quickly realized I was getting good answers 
but my approach was likely flawed from the start.

We are using Nginx just as a cache mechanism across many custom DNS names. As a 
result we have many server {} blocks handling a variety of different DNS names, 
vanity URLs and in a few cases SSL redirects. Where possible a single server {} 
block handles a wildcard DNS name but there are reasons we separate some of 
them out. Given the number of DNS entries, I have also created a system for 
creating *.conf files, so I do not use a single conf file for all the servers, 
instead I divide them out into many conf files. For special configuration items 
that are only included sometimes, I use *.inc files with the idea being that 
nginx.conf includes *.conf but does not include *.inc so that way I can make my 
server{} blocks cleaner and put common configurations into inc file. The main 
benefit being that almost all the config files fit on the screen without 
scrolling that much in VIM. 

Within each of these DNS instances we have a mix of login required content. We 
use three different login methods, IP whitelists, local user/password set in 
our CMS and then we use NetID via CAS/Shibboleth. We don’t want any of the 
login pages cached. 

The way we differentiate this relates to the mechanics on the backend of the 
web application. So we created a custom header called X-Secured-Page which is 
either true or false. In the event the value is true, we do not want to cache.

To go a step further, I have made use the add_header to set different headers 
for when we cache a page versus when we do not cache a page. The idea being 
that Tier1 support could view these headers to deflect support calls when 
things are working as intended but also to create Jira tickets with the custom 
header content when things do not seem to be working correctly. In addition to 
this, when the secure page is true, I use this setting proxy_pass_header 
Set-Cookie; but when the secured page is false I use this setting: 
proxy_hide_header Set-Cookie; As for why, it is actually the CAS/Shibboleth 
authentication that fails to work without this setting change. I could easily 
just always pass the cookie but I was trying to eliminate any noise I could. We 
have a fairly complicated stack given the Nginx passes most traffic to a server 
cluster that handles URL rewrites and Vanity URLs at a level we did not want to 
approach in Nginx. We may in the future but right now that is off the table 
given the complexity and work that went into the management interfaces used to 
handle the url rewrites the content owners use.

So my thought process started with a test for $http_x_secured_page which for 
obvious reasons would not work because I was failing to distinguish request 
versus response headers and am very new to Nginx.

Using the responses yesterday, I was 99% sure I had a working model nailed 
down. I had a map block that looked like this

Map $upstream_http_x_secured_page $nocache {
default “0”;
“true” “1”;
“false” “2”;
}

Then in my server block I had logic that looks like this

Server{

Location / {
If ($nocache = “1”) { return 418; }
If ($nocache = “2”) { return 419; };
}
}

Then I had a custom location for each, again this was all just to test and it 
worked. I used a combination of cURL and just using the inspector in firefox to 
see the headers and I was consistently getting the correct code from either the 
418 or 419 block. So I moved the same identical code into production but used a 
new server block. In all this testing I was working with a DNS name not yet put 
into Nginx, so I was using all HOSTS file manipulation. But the content of the 
Server block was accurate so the responses were correct. This is the same 
method I used to test every DNS name moved in and seemed like the simplest way 
to test in production, not to mention we run 4 nginx servers as part of a 
globally redundant solution, using the HOSTS file allows me to easily test 
against a single production server before rolling my configs to all servers. 

In trying to figure out the problem, I read about how the map{} block worked 
and was confused by it saying that it stores the last request made which caused 
me to wonder if the design I had with many server{} blocks all sharing the same 
map{} directive was somehow flawed so my testing in production was doomed from 
the start. I also really do not understand the order of operation taking place. 
If the map{} took place inside a server block, then I would understand it 
better and see it encapsulated from other server{} requests. Or if I was to use 
upstream{} blocks and it went inside that, again I would understand it more.

I did try implementing upstream{} sections but it did not seem to make sense, I 
only had one server defined inside of it and since I did 

Re: Response Header IF statement problem

[webopsx]

Hi,

Yes NGINX can inspect the header, See the following full example. It will
check for the match of "true" case-insensitive. I am simulating your backend
on port 81. Does this make sense?

map $upstream_http_x_secured_page $nocache {
~*true  "1";
default "";
}

upstream backend {
server 127.0.0.1:81;
}

server {
listen   80;
server_name  localhost;

#charset koi8-r;
#access_log  /var/log/nginx/log/host.access.log  main;

location / {
proxy_no_cache $nocache;
add_header X-No-Cache-Status $nocache;
proxy_pass http://backend;
}

error_page   500 502 503 504  /50x.html;
location = /50x.html {
root   /usr/share/nginx/html;
}

}

server {

listen 81;

location / {
add_header X-Secured-Page "True";
return 200 "OK\n";
}

}


# testing

root@dev:/etc/nginx/conf.d# curl -I localhost   

   
HTTP/1.1 200 OK
Server: nginx/1.13.7
Date: Wed, 14 Feb 2018 21:59:55 GMT
Content-Type: application/octet-stream
Content-Length: 3
Connection: keep-alive
X-Secured-Page: True
X-No-Cache-Status: 1

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,278558,278578#msg-278578

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Response Header IF statement problem

[Friscia, Michael]

Maybe that’s the problem, I want to disable cache if the response header is 
true but not do anything if it is false. I can change my logic in creating this 
header to only have it on pages where cache should be disabled if it is not 
possible to use an IF statement around it. I will post my config here once I 
get rid of the sensitive things, but the confusing thing is that it worked, 
then it stopped working. 


 
___

Michael Friscia

Office of Communications
Yale School of Medicine

(203) 737-7932 – office
(203) 931-5381 – mobile
 
http://web.yale.edu


 

On 2/14/18, 4:39 PM, "nginx on behalf of webopsx"  wrote:

Hi,

The map is processed on each request and should be very consistent. 

I thought you wanted to disable cache on the existence of a response header,
not a request header.

Otherwise I think we need more information to understand, such as how are
you testing? Perhaps paste your full configuration here after removing any
sensitive text.

Posted at Nginx Forum: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__forum.nginx.org_read.php-3F2-2C278558-2C278576-23msg-2D278576=DwICAg=cjytLXgP8ixuoHflwc-poQ=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs=x0V3h5hp-I18hCxDQuN0U7f_JYUQYISVWlygl1QK-FU=sUMR29LFjCI97P-LSb-RwuojlvhtDhvfRiX_YAio19E=

___
nginx mailing list
nginx@nginx.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.nginx.org_mailman_listinfo_nginx=DwICAg=cjytLXgP8ixuoHflwc-poQ=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs=x0V3h5hp-I18hCxDQuN0U7f_JYUQYISVWlygl1QK-FU=833NZxJsLHFd1YlQmOtXp22oR4K0OXPS-xz0mYs6r04=


___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Response Header IF statement problem

[webopsx]

Hi,

The map is processed on each request and should be very consistent. 

I thought you wanted to disable cache on the existence of a response header,
not a request header.

Otherwise I think we need more information to understand, such as how are
you testing? Perhaps paste your full configuration here after removing any
sensitive text.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,278558,278576#msg-278576

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Response Header IF statement problem

[Friscia, Michael]

Ok, so I did this and it worked and then it stopped working, then it worked 
again and then stopped working. I literally used the code below, the map 
appears right above my server {}  block. When it worked I was passing a header 
with the $nocache value set and it was consistently returning the correct 
value. What I don’t understand is that I did not change the code that runs 
this, I made some other non related changes and then this stops working.

What would cause the map directive to stop working? Or maybe my question is 
what would cause the map directive to cache a value to that variable and then 
not change it even with nginx restarts?

___
Michael Friscia
Office of Communications
Yale School of Medicine
(203) 737-7932 - office
(203) 931-5381 - mobile
http://web.yale.edu 
 

On 2/14/18, 10:35 AM, "nginx on behalf of webopsx"  wrote:

You can use map for this...

 - 
https://urldefense.proofpoint.com/v2/url?u=http-3A__nginx.org_en_docs_http_ngx-5Fhttp-5Fmap-5Fmodule.html-23map=DwICAg=cjytLXgP8ixuoHflwc-poQ=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs=csqe7S6wi1lA0kyhdVj1SfeveAOmZWbSQEv2optF3DM=T2K9F3KlskBzpELc7oj9imZ4p2BYuKpKw_5q-LFmuNI=

map $upstream_http_x_secured_page $nocache {
"search string" "1"
default "";
}

location /foo {
...
proxy_no_cache $nocache;
}

Posted at Nginx Forum: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__forum.nginx.org_read.php-3F2-2C278558-2C278563-23msg-2D278563=DwICAg=cjytLXgP8ixuoHflwc-poQ=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs=csqe7S6wi1lA0kyhdVj1SfeveAOmZWbSQEv2optF3DM=165qUkBDlSIz9uoSMkUjKmbUovmlJdt3fBGdYfNEKcU=

___
nginx mailing list
nginx@nginx.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.nginx.org_mailman_listinfo_nginx=DwICAg=cjytLXgP8ixuoHflwc-poQ=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs=csqe7S6wi1lA0kyhdVj1SfeveAOmZWbSQEv2optF3DM=8K1QknyjZyQW-6l2izUg26ej0rKE49EN2u5NQ-vGEuI=


___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Response Header IF statement problem

[Friscia, Michael]

Ok, I think this sends me into the correct direction. Thanks for posting the 
links and explaining the _bypass, I was setting both _bypass and _no_cache 
because I wasn’t sure.

___
Michael Friscia
Office of Communications
Yale School of Medicine
(203) 737-7932 - office
(203) 931-5381 - mobile
http://web.yale.edu 
 

On 2/14/18, 10:03 AM, "nginx on behalf of webopsx"  wrote:

Hi,

If I understand correctly you actually don't want to cache specific
responses (not bypass). The proxy_cache_bypass is only for if the response
has already been cached and defines the behavior in which NGINX should serve
the cached version to a client. 

Therefore if I understand correctly, you should be using the upstream module
for your origin definition and the proper variable will be available as
$upstream_http_x_secured_page
 -

https://urldefense.proofpoint.com/v2/url?u=http-3A__nginx.org_en_docs_http_ngx-5Fhttp-5Fupstream-5Fmodule.html-23var-5Fupstream-5Fhttp-5F=DwICAg=cjytLXgP8ixuoHflwc-poQ=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs=uDTsErKM0Hidc5iw_7R5NJrlwOfkoJbgLxL4BJmCY5I=QEt-4cOG5TsUmuMUu8UNGiNid6whJR-CBqlmzBdUC78=

Then use the proxy_no_cache directive to determine what should and should
not be cached in your configuration. If you want to simply check if the
header exists and then not cache the response, you can add the
upstream_http_ variable as a parameter. 
 - 
https://urldefense.proofpoint.com/v2/url?u=http-3A__nginx.org_en_docs_http_ngx-5Fhttp-5Fproxy-5Fmodule.html-23proxy-5Fno-5Fcache=DwICAg=cjytLXgP8ixuoHflwc-poQ=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs=uDTsErKM0Hidc5iw_7R5NJrlwOfkoJbgLxL4BJmCY5I=5JotmehkLwuEdHep18iz8JzWFD5LRfgDzAOuV_y8DwA=

If you need to inspect the header, then look into using map instead to
define the conditions you need in other to set or not set the proxy_no_cache
to a value or not.

Please let me know if my understanding is correct.

Posted at Nginx Forum: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__forum.nginx.org_read.php-3F2-2C278558-2C278561-23msg-2D278561=DwICAg=cjytLXgP8ixuoHflwc-poQ=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs=uDTsErKM0Hidc5iw_7R5NJrlwOfkoJbgLxL4BJmCY5I=UrVYW4V-vb5FY0oXMikgzaPAKrNuFPAz897blNCH_p8=

___
nginx mailing list
nginx@nginx.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.nginx.org_mailman_listinfo_nginx=DwICAg=cjytLXgP8ixuoHflwc-poQ=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs=uDTsErKM0Hidc5iw_7R5NJrlwOfkoJbgLxL4BJmCY5I=AIsbNagy7Mrq1Xd-D4En3kAzGjRXaS05L_e68spvhhE=


___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Response Header IF statement problem

[webopsx]

You can use map for this...

 - http://nginx.org/en/docs/http/ngx_http_map_module.html#map

map $upstream_http_x_secured_page $nocache {
"search string" "1"
default "";
}

location /foo {
...
proxy_no_cache $nocache;
}

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,278558,278563#msg-278563

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Response Header IF statement problem

[Friscia, Michael]

Thank you Roman, but this raises a different question, if I want to base this 
on the value and not the existence, is that still possible?

___
Michael Friscia
Office of Communications
Yale School of Medicine
(203) 737-7932 - office
(203) 931-5381 - mobile
http://web.yale.edu 
 

On 2/14/18, 10:00 AM, "nginx on behalf of Roman Arutyunyan" 
 wrote:

Hi Michael,

On Wed, Feb 14, 2018 at 02:09:57PM +, Friscia, Michael wrote:
> I’m at a loss on this. I am working on a cache problem where some pages 
need to be bypassed and others will be cached. So the web server is adding a 
response header (X-Secured-Page). I’ve tried multiple combinations of
> $http_x_secured_page and $sent_http_x_secured_page and even though I see 
the header when I inspect the page, the IF statements inside the location block 
are not getting fired off.
> 
> What could I possibly be doing wrong?

If you want to disable caching for a specific response, you can use the
proxy_no_cache directive.  Pass it $upstream_http_x_secured_page if you want
to disable caching of responses having this HTTP header.

Using "if" directive for analyzing output headers like 
$sent_http_x_secured_page
will not work since "if" is evaluated at an early request processing stage
(rewrite phase) and no output is normally created by this time.

-- 
Roman Arutyunyan
___
nginx mailing list
nginx@nginx.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.nginx.org_mailman_listinfo_nginx=DwIGaQ=cjytLXgP8ixuoHflwc-poQ=wvXEDjvtDPcv7AlldT5UvDx32KXBEM6um_lS023SJrs=fbY3_x6ACbtIV55mcZsfJMVepTuuqXtt2QkwBQ_DlOg=yQYgAxzpG-gYD_SClb9BufTDkAIZfHQ2POVAXyIeCno=

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Response Header IF statement problem

[Roman Arutyunyan]

Hi Michael,

On Wed, Feb 14, 2018 at 02:09:57PM +, Friscia, Michael wrote:
> I’m at a loss on this. I am working on a cache problem where some pages need 
> to be bypassed and others will be cached. So the web server is adding a 
> response header (X-Secured-Page). I’ve tried multiple combinations of
> $http_x_secured_page and $sent_http_x_secured_page and even though I see the 
> header when I inspect the page, the IF statements inside the location block 
> are not getting fired off.
> 
> What could I possibly be doing wrong?

If you want to disable caching for a specific response, you can use the
proxy_no_cache directive.  Pass it $upstream_http_x_secured_page if you want
to disable caching of responses having this HTTP header.

Using "if" directive for analyzing output headers like $sent_http_x_secured_page
will not work since "if" is evaluated at an early request processing stage
(rewrite phase) and no output is normally created by this time.

-- 
Roman Arutyunyan
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx