Different behaviour than stock nginx commands with index/location

[rugk]

the echo directive comes not from nginx, but from some 3rd-party module. It can have lower quality of code and unpredictable behaviour.

So if you want to fix that :laughing:, have a look at the whole description: https://serverfault.com/questions/771886/nginx-is-ignoring-root-location-header-location

[agentzh]

@rugk I don't have the time to look at the whole serverfault thread. If you think this module has issues, please elaborate here. Simply saying "lower quality" and "unpredictable behaviour" is not helpful at all, but actually insulting I'm afraid.

[agentzh]

@rugk Please see below on how to properly report a problem: http://openresty.org/en/faq.html#how-should-i-report-a-problem Thanks for your cooperation.

[rugk]

Come on. The thread is not soon long and in the original post I described the problem in detail.

Basically it means the "echo" command is executed in a specific situation where usual nginx commands are not executed.

[agentzh]

Please elaborate here. Or I'll have to close this ticket.

[rugk]

I have self-compiled nginx 1.9.14 with http2 support:

nginx version: nginx/1.9.14
built by gcc 4.9.2 (Debian 4.9.2-10) 
built with OpenSSL 1.0.1k 8 Jan 2015
TLS SNI support enabled

So I have a location = / block in my config, which should add a header only when the user accesses the root site (https://myserver.example.com/). However when I access my server in Firefox the header in the / location block (which is WhereIAm) is not added:

Content-Encoding: gzip
Content-Type: text/html
Date: Thu, 21 Apr 2016 07:12:11 GMT
Etag: W/"570bf892-363"
Last-Modified: Mon, 11 Apr 2016 19:18:42 GMT
Server: nginx
Strict-Transport-Security: max-age=15768000; includeSubDomains;  preload
X-Content-Type-Options: nosniff
X-Firefox-Spdy: h2
headerend: AtTheEnd
testing: IsTLS
x-something: ALsoAtTheEnd

This is my nginx config:

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        server_name myserver.example.com;
        root /var/www/html;

        server_tokens off;

        index index.php index.html index.htm;

        # -- TEST BEGIN --

        location = /configtest {
                #echo "itworks";
                add_header itworks configtest;
        }

        add_header testing IsTLS;

        location = / {
                add_header WhereIAm Is:/;
        }
        location /testdir1 {
                add_header WhereIAm Is:/testdir1;
        }
        location = /testdir2 {
                add_header WhereIAm Is:/testdir2;
        }

        # -- TEST END --
}

So in contrast when I access https://myserver.example.com/testdir1/ (and testdir1 is a directory, which exists on my server) it adds the correct header:

Content-Encoding: gzip
Content-Type: text/html
Date: Thu, 21 Apr 2016 07:24:22 GMT
Etag: W/"571538f2-363"
Last-Modified: Mon, 18 Apr 2016 19:43:46 GMT
Server: nginx
X-Firefox-Spdy: h2
whereiam: Is:/testdir1

echo command here! What's more confusing is when I change the location block to this:

location = / {
    echo "ThisIsATest";
    add_header WhereIAm Is:/;
}

Nginx does not only return the test string when accessing it, but it also adds the correct header:

Content-Type: application/octet-stream
Date: Thu, 21 Apr 2016 07:32:01 GMT
Server: nginx
X-Firefox-Spdy: h2
whereiam: Is:/

[agentzh]

@rugk Your original location = / does not use ngx_echo's directive at all and I don't see why you report the issue under this module and claims that it's ngx_echo's "lower quality" and "unpredictable behavior".

Regarding your issue, it is because of how nginx's standard "index" directive is implemented. Basically, when you access locaton = /, that location inherits your index directive configuration in the outer scope:

index index.php index.html index.htm;

So when index is run, it initiates an "internal direct" and leaves the current location block and finds a new location block for the new URL /index.html (if index.html is found on your local file system, for example), thus bypassing your add_header configuration (and everything else) in the original location = / location altogether.

You can see all these details when you (temporarily) enable the nginx debugging logs, as documented here:

http://nginx.org/en/docs/debugging_log.html

So from I've seen so far, it is your misunderstanding of the behavior of standard nginx configuration directives (index and add_header in this case) which have nothing to do with this ngx_echo module. Please remove your false information and wrong statements about this module from all the public places, thank you.

[rugk]

claims that it's ngx_echo's "lower quality" and "unpredictable behavior".

This were not my words. I quoted these from a Stackoverflow commenter.

So from I've seen so far, it is your misunderstanding of the behavior of standard nginx configuration directives (index and add_header in this case) which have nothing to do with this ngx_echo module.

If this is right, then that's good (for this echo module). So this is expected behaviour?

Please remove your false information and wrong statements about this module from all the public places, thank you.

Yes, sir. I will start censoring myself right now to protect the image of echo-nginx-module. The issue is just █ █ ' █ █ █ █ █ █ █ talk █ █ █ █ █ █ ' █ █ █ █ █ █ █ ' █ █ █ █ █ . I hope you allow me to print this issue out and pin it on my wall. I will not show my wall anyone afterwards.

(seriously)

[rugk]

Thanks for your explanation and I think this issue has been resolved.