1. 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

Discussion in 'Troubleshooting and Problems' started by Basilio, Nov 24, 2011.

  1. Basilio

    Basilio Member

    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:
    (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:
    (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:
    (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.
  2. Jake Bunce

    Jake Bunce XenForo Moderator Staff Member

  3. Basilio

    Basilio Member

    If I turn off friendly URLs, it works fine.

    It definitely is connected with the following condition in the nginx config:
            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?
  4. Basilio

    Basilio Member

    These rewrite rules are for a standalone install of nginx+fastcgi. I'm using nginx as caching proxy + apache, not sure how to update the nginx config in that case.
  5. Jake Bunce

    Jake Bunce XenForo Moderator Staff Member

  6. Basilio

    Basilio Member

    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
    did help, and now nginx correctly serves the request by forwarding it to apache.
    high1976 likes this.
  7. Jake Bunce

    Jake Bunce XenForo Moderator Staff Member

    Interesting. I noticed the unescaped "." but that still didn't explain the problem.

    The docs actually have an example of this:


    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:


  8. Basilio

    Basilio Member

    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.

Share This Page