2

we have two nginx servers. The first server receives a request via www.example.com/partner. He sends the whole request to the second server which has php+fastCgi configured. Nginx access log from second server:

"GET /partner/ HTTP/1.0" 200 2845

On the second server I have a vhost that looks like that:

server {
       listen my.ip:80;
       server_name www.example.com;
       root /var/www/example;

       if ($http_host != "www.example.com") {
                 rewrite ^ http://www.example.com$request_uri permanent;
       }

       index index.php index.html;


       location = /partner/favicon.ico {
                log_not_found off;
                access_log off;
                expires max;
       }


        location @nocache {
                try_files $uri $uri/ /index.php?$args;
       }
       location = /partner/robots.txt {
                allow all;
                log_not_found off;
                access_log off;
       }

       location ^~ /partner/typo3temp/tx_ncstaticfilecache {
                expires 43200;
                charset utf-8;
       }

       location = /partner/clear.gif {
                empty_gif;
                expires max;
       }
       location ^~ /partner/typo3/gfx {
                expires max;
       }
       location ^~ /partner/typo3temp/compressor {
                expires max;
       }   

    location /partner {    


                if ($query_string ~ ".+") {
                        return 405;
                }
                # pass requests from logged-in users to PHP
                if ($http_cookie = 'nc_staticfilecache|be_typo_user' ) {
                        return 405;
                } # pass POST requests to PHP
                if ($request_method !~ ^(GET|HEAD)$ ) {
                        return 405;
                }
                if ($http_pragma = 'no-cache') {
                        return 405;
                }
                if ($http_cache_control = 'no-cache') {
                        return 405;
                }
                error_page 405 = @nocache;

                # serve requested content from the cache if available, otherwise pass the request to PHP
                try_files /typo3temp/tx_ncstaticfilecache/$host${request_uri}index.html @nocache;


       location ~* \.(sql|htaccess|htpasswd|tpl|html5|xhtml) {
                deny all;
       }

       location ~*  \.(jpg|jpeg|png|gif|css|js|ico)$ {
                expires max;
                log_not_found off;
       }

       location ~* \.(cur|ico|gif|png|jpe?g|css|js|swf|woff)((\?\d\d\d\d\d\d\d\d\d\d)|(\?s=\d\d\d\d\d\d\d\d\d\d))$ {
                expires max;
                log_not_found off;
       }
       location ~* \.(cur|ico|gif|png|jpe?g|css|js|swf|woff)(\?v\d\d?\.\d\d?\.\d\d?)$ {
                expires max;
                log_not_found off;
       }
       location ~* ^(/typo3/sysext|/typo3conf/ext).*\.(cur|ico|gif|png|jpe?g|css|js|swf|woff) {
                expires max;
                log_not_found off;
       }



       location ~ /\. {
                deny all;
                access_log off;
                log_not_found off;
       }

       location ~ \.php$ {
                try_files $uri =404;
                include /etc/nginx/fastcgi_params;
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_index index.php;
       }
    }
}

The problem that the that I get and 403 Error. Any ideas whats wrong?

DarkLeafyGreen
  • 69,338
  • 131
  • 383
  • 601
  • can you set the error_log to debug and paste it somewhere? my guess is that the location ~ \.php$ block isn't being evaluated because nginx is finding the file on the file system. – pcting Apr 28 '12 at 23:21

1 Answers1

1

Most likely reason for the php files being downloaded because the php handling location block in nested under another location block (This assumes php has been correctly setup).

Overall, your config seems overly complicated and I am sure whatever task it is doing can be done with a far more straightforward configuration.

I have done a basic clean up / consolidation but not having a full picture, some bits may be off. Should give you some ideas though.

Important thing though regarding the PHP is pulling it out of the nested location.

Also, using Status Code 418 instead of 405 for redirection as 405 can be legitimately generated for other reasons.

Using a separate server block for the example.com to www.example.com redirection for better performance.

server {
    listen my.ip:80;
    server_name example.com;
    rewrite ^ http://www.example.com$request_uri? permanent;
}

server {
    listen my.ip:80;
    server_name www.example.com;
    root /var/www/example;
    index index.php index.html;
    error_page 418 = @nocache;

    if ($query_string ~ ".+") {
        return 418;
    }
    # pass requests from logged-in users to PHP
    if ($http_cookie = 'nc_staticfilecache|be_typo_user' ) {
        return 418;
    } 
    # pass POST requests to PHP
    if ($request_method !~ ^(GET|HEAD)$ ) {
        return 418;
    }

    location = /partner/robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    location ^~ /partner/typo3temp/tx_ncstaticfilecache {
        expires 43200;
        charset utf-8;
    }

    location = /partner/clear.gif {
        empty_gif;
        expires max;
    }

    location ^~ /partner/typo3/gfx {
        expires max;
    }
    location ^~ /partner/typo3temp/compressor {
        expires max;
    }

    location /partner {
        # serve requested content from the cache if available, 
        # otherwise pass the request to PHP
        try_files /typo3temp/tx_ncstaticfilecache/$host${request_uri}index.html @nocache;
    }

    location ~* \.(sql|tpl|html5|xhtml) {
        deny all;
    }

    location ~*  \.(jpg|jpeg|png|gif|css|js|ico)(.*)$ {
        expires max;
        log_not_found off;
    }

    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }

    location ~ \.php$ {
        return 418;
    }

    location @nocache {
        try_files $uri =404;
        include /etc/nginx/fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_index index.php;            
    }
}
Dayo
  • 12,413
  • 5
  • 52
  • 67
  • nevermind you missed the return 418; But that does not solve the problem, I get a 404 error – DarkLeafyGreen Apr 29 '12 at 09:04
  • The 404 error may mean that this line 'try_files $uri =404;' in the nocache block is getting hit. You can try changing it to 403 to confirm. If it does give you a 403 error, then the structure of the config as posted is fine and the problem is in the detail of what appears to be an overly complicated config. I am not sure "/typo3temp/tx_ncstaticfilecache/$host${request_uri}index.html" is supposed to return for instance. The "${request_uri}" bit for instance. You will need to sort all those types of things out if the structure works as expected. I.E., PHP calls end up in the nocache block. – Dayo Apr 29 '12 at 09:17
  • Yes it gives me 403 now. Typo3temp contains cached files. I am messing around with that problem for some days now unable to solve it... – DarkLeafyGreen Apr 29 '12 at 09:24
  • Also, you might want to just use "listen 80" and leave out the ip if there is no specific reason for it to be there. – Dayo Apr 29 '12 at 09:24
  • as a notice, exactly that config worked when the request was coming from example.com/. As I changed it to example.com/partner it broke. So I thought adding /partner to all location blocks would solve it but as you see its 403 now... – DarkLeafyGreen Apr 29 '12 at 09:40
  • Why not use "try_files /partner/typo3temp/tx_ncstaticfilecache/$host${request_uri}index.html" ... (missing "/partner")? Also, do you absolutely need "try_files $uri =404;"? This might not be appropriate if the $uri does not actually physically exist. For instance, "location ~ /\.(.*)$ { return 403; }" basically does the same job as that try_files and may be more appropriate depending. Basically, from what I can see, the overall nginx structure now works as expected and it is now down to your understanding of the specific application you are using to sort out the specifics. – Dayo Apr 29 '12 at 09:58