2

This URL is invalid: http://mysite.co.uk/assets/images/whymysite/viewoptions.png

However, if I replace the 's' at the end before .png, with ANY other standard character (that I've tried so far, it works fine. ALSO, I had previously been using viewoptions.jpg - and THAT works fine. It seems to be specifically s.png that is triggering it, or so it seems.

I've had some other baffling 404s trying to load images, that I suspect were probably symptoms of the same issue, that I worked around by just randomly renaming the images, out of last-minute-rush desperation!

Everything else is working as expected, but this is driving me crazy! I am new to nginx and more coder than sysadmin so feel free to laugh at my obvious mistake, whatever it is :)

My nginx config for this site is:

server {
    listen          80;
    server_name     mysite.co.uk;
    root            /var/www/mysite/public/;
    index           index.php index.html;

    access_log      /var/www/mysite/logs/access.log;
    error_log       /var/www/dmysite/logs/error.log;

    try_files       $uri    $uri/   /index.php?q=$uri&$args;

    location ~* .(jpg|jpeg|gif|css|png|js|ico|eot|svg|ttf|woff)$ {
            access_log        off;
            expires           30d;
    }

    # pass PHP scripts to FastCGI server listening on 127.0.0.1:9000

    location ~ \.php$ {
            include         fastcgi_params;
            fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
            try_files       $uri =404;
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_index   index.php;
            fastcgi_pass    127.0.0.1:9000;
    }

}

Here are some log entries. First, the error log entry for 'viewoptions.png'

2011/09/28 17:24:34 [error] 4241#0: *11 open() "/var/www/mysite/public/assets/images/whymysite/viewoptions.png" failed (2: No such file or directory), client: 192.168.0.2, server: mysite.co.uk, request: "GET /assets/images/whymysite/viewoptions.png HTTP/1.1", host: "mysite.co.uk", referrer: "http://mysite.co.uk/why-mysite.php"

Now, the access.log entries for the other filenames that do work. A different extension, removing the 's', adding one or more characters in replace of the 's'? All fine!

192.168.0.2 - - [28/Sep/2011:17:24:14 +0100] "GET /assets/images/whymysite/viewoptions.jpg HTTP/1.1" 304 0 "http://mysite.co.uk/why-mysite.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1"
192.168.0.2 - - [28/Sep/2011:17:24:34 +0100] "GET /assets/images/whymysite/viewoptions.png HTTP/1.1" 404 201 "http://mysite.co.uk/why-mysite.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1"
192.168.0.2 - - [28/Sep/2011:17:24:43 +0100] "GET /assets/images/whymysite/viewoption.png HTTP/1.1" 304 0 "http://mysite.co.uk/why-mysite.php"
192.168.0.2 - - [28/Sep/2011:17:24:59 +0100] "GET /assets/images/whymysite/viewoptionqqq.png HTTP/1.1" 200 3486 "http://mysite.co.uk/why-mysite.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1"
Andrew
  • 21
  • 3
  • Could you please show us some 404 error logs when loading images? – quanta Sep 28 '11 at 15:47
  • Good idea. Okay, the first line is the error.log entry I get when trying to load in 'viewoptions.png' - after that I've included the access.log entries for all the other, similar filenames that all work fine. Amended main entry to show this. – Andrew Sep 28 '11 at 16:29
  • @Andrew Do you know what was the solution to this? – Nishant Nov 08 '13 at 13:06

1 Answers1

1

Just remove this portion :

location ~* .(jpg|jpeg|gif|css|png|js|ico|eot|svg|ttf|woff)$ {
        access_log        off;
        expires           30d;
}

Because now you are fighting against your browser cache only.

jflaflamme
  • 306
  • 1
  • 2
  • It's not that - I added that in afterwards whilst researching the problem, because it seemed like a worthwhile addition. I'm certain it's also not browser cache-related. – Andrew Sep 28 '11 at 12:27
  • You should remove it if you don't want unexpected results while debugging your problem, try with the firebug panel to check the real query and reply about this file ( and if it is cached ). – jflaflamme Sep 28 '11 at 12:29