[RÉSOLU] Problème avec nginx et MyBetterUrls

PPmarcel · juillet 2014

Bonjour,

Ce week-end j'ai voulu installer nginx et tester PluXML par dessus. Après avoir recherché quelques ressources traitant le sujet, j'ai mis en place une petite conf me permettant d'utiliser la réécriture d'URL.

Jusqu'ici, tout marche bien, et le chemin des articles correspondent à /articleXX/titre-du-billet.

En revanche, si j'active le plugin MyBetterUrls, les URL sont raccourcies sans /articleXX. Normal.
Mais certains articles fonctionnent, et d'autres aboutissent sur du 404. Et je ne parviens pas à trouver le point commun entre ceux qui marchent ou non.

De l'autre côté avec un couple apache/varnish, tout fonctionne sans soucis.

D'après le contenu du .htaccess situé à la racine, les règles de réécriture trouvent bien leur équivalence dans nginx.

Voici ma configuration nginx pour PluXML :

server {
    listen       82;
    server_name  preprod;
    root         /var/www/preprod;

    access_log  /var/log/nginx/preprod-access.log;
    error_log  /var/log/nginx/preprod-error.log;

    index index.php;

    # URL Rewriting
    if (!-e $request_filename) {
        rewrite ^/([^feed\/].*)$ /index.php?$1 last;
    }

    rewrite ^/feed\/(.*)$ /feed.php?$1 last;


    # Security
    location ~ /\.ht {
        deny  all;
    }

    # Stuffs
    location = /favicon.ico {
        access_log   off;
        return   204;
    }

    location ~* ^.+\.(jpg|jpeg|gif|css|png|js|xml)$ {
        expires     30d;
    }

    #directory protection
    location ^~ /data/configuration/ {
        deny all;
    }
    location ^~ /version {
        deny all;
    }
    location ^~ /update {
        deny all;
    }
   location /data/configuration/users.xml {
        deny all;
   }


    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini

        # With php5-fpm:
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }


}

Dans les logs d'erreur, je tombe sur ça lorsque j'ai des URL défectueuses :

2014/07/29 19:18:56 [error] 9837#0: *717 open() "/var/www/preprod/fribourg-en-brisgau.html" failed (2: No such file or directory), client: xx.xx.xx.xx, server: preprod.xxxxxxx, request: "GET /fribourg-en-brisgau.html HTTP/1.1", host: "preprod.xxxx:82", referrer: "http://preprod.xxxxx:82/"

C'est à croire que l'index de pluxml n'effectue par la réécriture requise.

Du coup je suis un peu bloqué sur ce point et je ne vois pas trop comment corriger ce problème.
Quelqu'un aurai-t-il des idée pour m'aider à avancer sur le diagnostique ?

J'ai la main sur mon serveur, si il faut tester des paramètres spécifiques.

Matthieu

PPmarcel · juillet 2014

Un petit conseil, des idées ? Voire même un outil de debug si il faut en arriver là ?

Frédéric · juillet 2014

Bonsoir PPmarcel,

Peut tu essayer ce fichier nginx:

if (!-f $request_filename){
	set $rule_0 1$rule_0;
}
if (!-d $request_filename){
	set $rule_0 2$rule_0;
}
if ($request_filename !~ "-l"){
	set $rule_0 3$rule_0;
}
if ($rule_0 = "321"){
	rewrite ^/(?!feed)(.*)$ /index.php?$1 last;
}
	rewrite ^/feed/(.*)$ /feed.php?$1 last;

Cela représente la config de base sans superflus dans un premier temps.

PPmarcel · juillet 2014

Bonsoir Frédéric,

J'ai essayé ta configuration. Il y a eu une inversion de situation : certains articles qui étaient accessibles sont passés en 404, d'autre sont passés d'un 404 à un bon fonctionnement (200), tandis que les autres n'ont pas changé d'état (retour 200 ou 404).

Mais en regardant les expressions de près, je vois que ton expression de réécriture est différente de celle que j'utilise :

rewrite ^/(?!feed)(.*)$ /index.php?$1 last;
au lieu de 
rewrite ^/([^feed\/].*)$ /index.php?$1 last;

En réutilisant le bloc de départ mais en changeant la réécriture, tous les articles fonctionnent !

Il s'agissait donc d'un problème de réécriture côté conf nginx, et non pas un problème lié au plugin.

Merci pour ton aide.

Frédéric · juillet 2014

Ha cool, mais bon cela devrait fonctionner sans rien modifier à cette config.

Peut tu essayer en désactivant le plugin MyBetterUrls stp ?

Car ta solution pourrais être un fixe pour le plugin en attendant que Stéphane regarde de son coté. Mais à confirmez si la configuration donné plus haut fonctionne pour un PluXml vierge.

PPmarcel · août 2014

A chaque fois j'ai testé les 10 derniers articles. Avec ta configuration :
[list=*]
[*]Sans plugin MyBetterUrls : erreurs 404 et bon retours 200 selon les pages[/*]
[*]Avec plugin MyBetterUrls : exactement les mêmes erreurs 404 et retours 200[/*]
[/list]

Note : lorsque je suis venu demander de l'aide au forum, les erreurs 404 restaient toujours sur les même articles, mais les articles en erreurs étaient différent de ceux que j'ai testé avec ta configuration.

Je ne parviens pas à trouver ce qui fait que les 404 ne sont pas aléatoires, ce sont les même pages qui entrent en erreur.

Avec la solution fonctionnelle dans mon cas : tout marche avec et sans le plugin.

Afin d'éviter toute ambiguité, je te redonne le bloc de réécriture qui marche (nginx 1.2.1) :

    if (!-e $request_filename) {
        rewrite ^/(?!feed)(.*)$ /index.php?$1 last;
    }

    rewrite ^/feed\/(.*)$ /feed.php?$1 last;

PPmarcel · août 2014

Bon, j'ai fini par comprendre ce qui n'allait pas dans mon expression du début.

On a l'expression régulière qui dit que si l'URL ne commence pas par "feed/", alors on réécrit avec "index.php$url". Or la détection du pattern est écrite avec des crochets : "[^feed\/]".

Je ne sais pas comment ça se fait que chez certains ça marche bien, mais chez moi ce n'est pas le mot "feed" qui est entendu, mais c'est "si le chemin commence par un 'f', ou un 'e', ou un 'd', alors on ne réécrit pas vers l'index".

Du coup les 404 arrivaient sur les noms de billets qui commençaient par ces lettres.

En revanche avec les parenthèse de "(?!feed)", c'est bien le mot "feed" qui est lu dans son intégralité, et là on n'a plus cette ambiguité.

Lorsque le plugin MyBetterUrls est désactivé, le chemin commence systématiquement par "/article". On commence par la lettre "a", la réécriture ne rencontre donc jamais d'exception.

Finalement, c'est bien un problème de conf nginx.

Par contre j'ai un comportement différent avec tes règles, et je n'en pas encore déterminé dans quelles conditions les 404 surviennent.

[RÉSOLU] Problème avec nginx et MyBetterUrls

Réponses