weird problem:response header is reset if upstream returns 500

hlee · 2018-05-26T03:10:18+00:00

I am trying to build an openresty alpine image with lua-openssl like soFROM openresty/openresty:alpine-fat# Set the versionENV RESTY_CONFIG_OPTIONS_MORE &quo...

weird problem:response header is reset if upstream returns 500

hlee

I have a openresty+php setup.

And in the openresty conf, I have the php location block configured like this:

location ~ [^/]\.php(/|$) {
   # Setup caching (Page Speed)
   set $is_php 1;
   add_header X-srcache-status $srcache_fetch_status;

the is_php is initialized to 0 in the server block.

What I'm planning to do here with the is_php variable is I want to tell whether a request is finally handled by the php location block. (Not sure whether I'm doing it in the right way, any suggestion/recommendation for detecting the location block would be highly appreciated)

I can use `if ngx.var.is_php == "1"` in most cases, however, I discovered that if there's something wrong in the php and it returns a 500 error, the is_php will be set to 0 and there won't be such `X-srcache-status` header in the response. What's happening here?

BTW, I also found some other weird behaviours of openresty which I can't explain.

1. I initially tried to use `if ngx.header["x-srcache-status"] ~= nil` to test whether the request is handled by the php location block (because it's added by the location block), however, it looks like ngx.header["x-srcache-status"] is always nil (also tried capitalized X, but same), but I can see it from the response! Any idea why?

2. I tried to log the response headers in header_filter_by_lua using `for k,v in pairs(ngx.header)`, but couldn't get anything, any thoughts?

3. why `ngx.var.is_php` has to be treated as a string, i.e. `ngx.var.is_php == "1"` not `ngx.var.is_php == 1`? Even I set it to be 1, not "1"?

Thanks & Best Regards

House

rpaprocki

Hi,

On Fri, May 25, 2018 at 12:10 PM, <h...@vendasta.com> wrote:

I have a openresty+php setup.
And in the openresty conf, I have the php location block configured like this:
location ~ [^/]\.php(/|$) {
   # Setup caching (Page Speed)
   set $is_php 1;
   add_header X-srcache-status $srcache_fetch_status;
the is_php is initialized to 0 in the server block.

What I'm planning to do here with the is_php variable is I want to tell whether a request is finally handled by the php location block. (Not sure whether I'm doing it in the right way, any suggestion/recommendation for detecting the location block would be highly appreciated)

I can use `if ngx.var.is_php == "1"` in most cases, however, I discovered that if there's something wrong in the php and it returns a 500 error, the is_php will be set to 0 and there won't be such `X-srcache-status` header in the response. What's happening here?

Without testing, I suspect that an error_page directive is overriding the value of the variable, given that handler likely doesn't have this particular set directive defined. You might want to double check your configs and enable debugging logging to confirm this.

BTW, I also found some other weird behaviours of openresty which I can't explain.

1. I initially tried to use `if ngx.header["x-srcache-status"] ~= nil` to test whether the request is handled by the php location block (because it's added by the location block), however, it looks like ngx.header["x-srcache-status"] is always nil (also tried capitalized X, but same), but I can see it from the response! Any idea why?

The ngx.header table provides access to the response headers. What phase are you checking this in? What does your code look like? A standalone example to highlight this might help shed some light on the situation.

It might also help to use some other tools like a packet capture to detect the response from your upstream. Don't fall into the trap of relying strictly on one part of your setup to do all the heavy lifting for you :)

2. I tried to log the response headers in header_filter_by_lua using `for k,v in pairs(ngx.header)`, but couldn't get anything, any thoughts?

ngx.header is not a regular Lua table. It cannot be iterated with pairs/ipairs.

3. why `ngx.var.is_php` has to be treated as a string, i.e. `ngx.var.is_php == "1"` not `ngx.var.is_php == 1`? Even I set it to be 1, not "1"?

This is function of how Nginx treats variables. You should not consider Nginx variables to treated the same way you'd expect a full scripting language to treat them (e.g., typing, etc). Have a read of http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#internals for a bit more context.

hlee

Hi rpaprocki

Thanks so much for your awesome explanation!

1. Yes, it's overridden by an error_page directive! That's exactly the reason!

2. I checked it in the header_filter_by_lua, the code looks like:

`if ngx.header["x-srcache-status"] ~= nil then ngx.log(ngx.DEBUG, "has x-srcache-status header") else ngx.log(ngx.DEBUG, "x-srcache-status missing") end `

And I can only see "x-srcache-status missing" from the log. I've tried both upper case X and lower case

For all other questions, Thanks so much for the amazing answer!

Thanks & Best Regards

House

On Friday, May 25, 2018 at 1:53:48 PM UTC-6, rpaprocki wrote:

Hi,
On Fri, May 25, 2018 at 12:10 PM, <hl...@vendasta.com> wrote:
I have a openresty+php setup.
And in the openresty conf, I have the php location block configured like this:
location ~ [^/]\.php(/|$) {
   # Setup caching (Page Speed)
   set $is_php 1;
   add_header X-srcache-status $srcache_fetch_status;
the is_php is initialized to 0 in the server block.

What I'm planning to do here with the is_php variable is I want to tell whether a request is finally handled by the php location block. (Not sure whether I'm doing it in the right way, any suggestion/recommendation for detecting the location block would be highly appreciated)

I can use `if ngx.var.is_php == "1"` in most cases, however, I discovered that if there's something wrong in the php and it returns a 500 error, the is_php will be set to 0 and there won't be such `X-srcache-status` header in the response. What's happening here?
Without testing, I suspect that an error_page directive is overriding the value of the variable, given that handler likely doesn't have this particular set directive defined. You might want to double check your configs and enable debugging logging to confirm this.

BTW, I also found some other weird behaviours of openresty which I can't explain.

1. I initially tried to use `if ngx.header["x-srcache-status"] ~= nil` to test whether the request is handled by the php location block (because it's added by the location block), however, it looks like ngx.header["x-srcache-status"] is always nil (also tried capitalized X, but same), but I can see it from the response! Any idea why?

The ngx.header table provides access to the response headers. What phase are you checking this in? What does your code look like? A standalone example to highlight this might help shed some light on the situation.

It might also help to use some other tools like a packet capture to detect the response from your upstream. Don't fall into the trap of relying strictly on one part of your setup to do all the heavy lifting for you :)

2. I tried to log the response headers in header_filter_by_lua using `for k,v in pairs(ngx.header)`, but couldn't get anything, any thoughts?

ngx.header is not a regular Lua table. It cannot be iterated with pairs/ipairs.

3. why `ngx.var.is_php` has to be treated as a string, i.e. `ngx.var.is_php == "1"` not `ngx.var.is_php == 1`? Even I set it to be 1, not "1"?

This is function of how Nginx treats variables. You should not consider Nginx variables to treated the same way you'd expect a full scripting language to treat them (e.g., typing, etc). Have a read of http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#internals for a bit more context.