/index results in a file download with Nginx

[Lartza]

Pico 1.0 and nginx 1.10.0 (mainline, but it currently matches stable)

I got Pico with rewriting working otherwise it seems, but the /index links that Pico creates for the front page are not passed to php-fpm and get downloaded instead. /, /sub, /sub/page etc. all work

Below is my current config, a bit cluttered but I wanted to be thorough. The other server blocks shouldn't matter though.

server {
    listen 80;
    listen [::]:80;

    listen 443 ssl;
    listen [::]:443 ssl;

    ssl_certificate fullchain;
    ssl_certificate_key privkey;

    server_name domain.com;

    include common.conf;
    return 301 https://www.domain.com$request_uri;
}

server {
    listen 80;
    listen [::]:80;

    server_name www.domain.com;
    return 301 https://www.domain.com$request_uri;
}

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

    ssl_certificate fullchain;
    ssl_certificate_key privkey;

    server_name  www.domain.com;

    root   /usr/share/nginx/html;

    location ~ \.php$ {
        fastcgi_pass   unix:/run/php-fpm/php-fpm.sock;
        fastcgi_index  index.php;
        include        fastcgi.conf;
        fastcgi_param PICO_URL_REWRITING 1;
    }

    location / {
        try_files $uri $uri/ /index.php?$uri&$args;
    }
}

[mayamcdougall]

I'm currently trying to reproduce your issue, but I'm not seeing this behavior. We did see it a lot when we were debugging our Nginx documentation, and it was usually related to a Regex rule being above PHP, causing the page to never actually get sent to php-fpm. This doesn't seem to be the issue in your case obviously, but I thought it was worth mentioning. A file being served as a download usually means that, for whatever reason, it wasn't sent to php-fpm.

One thing I'm seeing is that you don't have an index statement (eg index index.php;). This bit me at first when I was testing your config, but it has the opposite effect, causing / to fail, but not /index. Maybe you have an index line defined elsewhere, but if not, try adding it under your root line.

@PhrozenByte, do you see any glaring issues that could be causing this behavior?

[PhrozenByte]

@smcdougall: @Lartza initially pictured this issue on IRC and I wasn't able to solve it, so I suggested him to open this issue. I thought it would be best to let our nginx experts help him 😃

[mayamcdougall]

I'm far from an expert. 😖

I tested the two location blocks and they seem to work fine. When I tested it, I had to change the location of php-fpm.sock and fastcgi.conf; to match my own server, but other than the lack of index index.php I mentioned, everything worked as expected.

[mayamcdougall]

Okay, so I guess my question would be what file is downloaded? Is it Pico's index.php or Nginx's index.html. You'll have to actually check the contents of the downloaded file because it'll get its name from the URL.

The only thing I can think is that try_files is serving a static index file instead of moving on to the index.php rewrite.

[mayamcdougall]

Oh wait.... I think I derp-ed a bit here... I've had the wrong root folder on my testing domain this whole time due to some other stuff I was testing.

Okay, without any more info, I'd definitely say that it sounds like you've got a static file called index in your document root that's being served as a download. The try_files statement is finding that file and serving it first. Normally, it would not find a static file, then move on to using Pico.

Sorry, I've got to go for now, but I'll check back later. Let me know if this helps, and if not I'll try to work on it some more.

[Lartza]

index index.html index.htm index.php is defined in nginx.conf, I didn't see a difference defining index index.php; in the Pico config.

The file was surely pico, pico->run() or something like that and everything.

But the "problem" now is that the site works :P I rebooted my PC but otherwise nothing hasn't really changed. I think this was a cache (browser or CloudFlare) issue, even though that sounds a bit weird to me. But I can't think of anything else?

[mayamcdougall]

Okay. I figured you had index defined elsewhere. No, you don't need to define it again as long as you have it somewhere. I can't think of any other reasons why you'd have had this behavior. As I outlined, there's a lot of things that could cause it, but you've already got most of your bases covered.

I'm sure @PhrozenByte has told you, but our Nginx Configuration page is quite new and was written by a user who's far from an Nginx expert (Me 😆). It's got a decent amount of information though. There's also the discussion we had about it at #343.

If it was a cache issue, it could have been an issue with Nginx's cache, not your browser or CloudFlare. Nginx could have been caching its original index file at /usr/share/nginx/html/index.html due to some unusual cache settings... or something. I don't know much about caching though, so it's just more speculation. The odd behavior definitely seems like it was rooted in Nginx though.

Glad you've got it working now. We'll be around to try to help more if the issue comes up again. 😃