• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

XF 1.1 Problem with SEO-friendly links on nginx+apache2

#1
Hello. I'm having a strange problem on nginx+apache2. Any time I'm trying to change an avatar through control panel, I'm getting a 404, sent by nginx (apparently it doesn't get to apache at all). The nginx log is as follows:
Code:
(ip address) - - [24/Nov/2011:12:20:02 +0400] "GET /xf/account/avatar?&_xfRequestUri=/xf/account/personal-details&_xfNoRedirect=1&_xfToken=1,1322122798,96579aab03b2b60195eb0824f48a32c30aa49fc0&_xfResponseType=json HTTP/1.0" 404 168 "http://(site address)/xf/account/personal-details" "Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0"
According to apache logs, the request doesn't get there at all. In the same time, most other requests get served normally - i.e.
nginx log:
Code:
(ip address) - - [24/Nov/2011:12:19:58 +0400] "GET /xf/account/personal-details HTTP/1.0" 200 10468 "http://(site address)/xf/" "Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0"
apache log:
Code:
(ip address) - - [24/Nov/2011:12:19:58 +0400] "GET /xf/account/personal-details HTTP/1.0" 200 10826 "http://(site address)/xf/" "Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0"
I'm totally stuck as I really don't understand why the request for "/xf/account/personal-details" gets through to apache, while "/xf/account/avatar" gets bumped by nginx.

Any ideas?

PS I've an out-of-the box setup of XF, e.g. the .htaccess is standard.
 
#3
If I turn off friendly URLs, it works fine.

It definitely is connected with the following condition in the nginx config:
Code:
        location ~* ^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
            root   /var/www;
        }
When I remove that - everything works fine. However, then there is no point in using nginx. What should I change in the nginx config?
 

Jake Bunce

XenForo moderator
Staff member
#5
#6
Actually, what I need is nginx serving on itself all requests to static files, and proxying everything else further to apache.
In the end, it looks like I found the problem. Looks like nginx is simply ignoring the "$" in the regexp, and is treating the "js" part of the url (which is located in the "=json"). At least, changing the regexp to
Code:
^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$
did help, and now nginx correctly serves the request by forwarding it to apache.
 

Jake Bunce

XenForo moderator
Staff member
#7
Interesting. I noticed the unescaped "." but that still didn't explain the problem.

The docs actually have an example of this:

http://wiki.nginx.org/NginxHttpCoreModule#location

Code:
location ~* \.(gif|jpg|jpeg)$ {
  # matches any request ending in gif, jpg, or jpeg. However, all
  # requests to the /images/ directory will be handled by
  # Configuration C.   
  [ configuration D ] 
}
They use "$" to specify the end of the URI. I'm not sure why it's not working for you.

If your static content is in a specific directory then you can try naming that specific directory without matching file extensions. There is an example given for this:

http://wiki.nginx.org/NginxHttpCoreModule#root

Code:
location  /i/ {
  root  /spool/w3;
}
A request for "/i/top.gif" will return the file "/spool/w3/i/top.gif". You can use variables in the argument.
 
#8
Thanks for efforts guys, in the end it still is a problem inside nginx, which is rather unexpected.
The general idea of the setup I'm running is that nginx and apache are using the same root directories, but apache is serving all scripts, while nginx is serving all static content. The regexp is originally coming from a how-to on setting up such a config - I didn't pay too close attention to it, and obviously it contains a typo with that unescaped dot (or maybe I somehow broke it while playing with it) - which eventually in conjunction with nginx not processing the "$" led to these results.
Ah well, nice to find that out anyway.