2016-11-25 1 views
0

Avec quelques essais (ou beaucoup), j'ai pu modifier ma copie et coller la configuration php nginx fastcgi de quelque part il y a des années pour pouvoir exécuter mon application php dans un sous-dossier.nginx ne passe pas la chaîne de requête fastcgi

Mais la dernière étape que je ne suis pas en mesure de résoudre est comment obtenir nginx pour passer la chaîne de requête à PHP pour pouvoir accéder aux paramètres GET. Ceci est ma configuration essentiellement parfaite avec seulement les paramètres de configuration manquants:

server { 
    listen  80; 
    server_name project.dev; 

    location /app/ { 
     alias /path/to/my/application/; 
     index index.php; 
     try_files $uri $uri/ /app/index.php; 

     location ~ \.php$ { 
      include fastcgi_params; 
      fastcgi_pass 127.0.0.1:9000; 
      fastcgi_param SCRIPT_FILENAME $document_root/index.php; 
     } 
    } 

    location/{ 
     # configuration for static website 
    } 
} 

Je lis qu'il ya différentes options que vous devez passer à try_files pour obtenir des paramètres de demande:

  • try_files $uri $uri/ /app/index.php$is_args$query_string;
  • try_files $uri $uri/ /app/index.php$is_args$args;
  • try_files $uri $uri/ /app/index.php?$query_string;

Malheureusement changer à aucun de ces résultats dans mon script php ne sont plus trouvé parce que nginx remet à zéro la demande à elle racine du document:

2016/11/25 11:54:48 [error] 45809#0: *1169 open() "/usr/local/Cellar/nginx-full/1.10.2/htmlindex.php" failed (2: No such file or directory), client: 127.0.0.1, server: project.dev, request: "GET /app/myurl?test=works HTTP/2.0", host: "project.dev", referrer: "http://project.dev/app/myurl?test=works" 

Fournir un chemin absolu pour fastcgi_param SCRIPT_FILENAME ne fonctionne pas trop producting la même erreur. Même la définition d'une configuration root au niveau server ne fonctionne pas correctement, car la barre oblique de séparation du chemin et le index.php sont omis à chaque fois. Mais (si possible) je préférerais sans définir un répertoire racine au niveau du serveur car ce projet consiste en de nombreux dossiers et applications différents sur le système de fichiers partageant aucun répertoire commun.

+0

Qu'essayez-vous d'accomplir? Quels fichiers avez-vous sous '/ chemin/vers/mon/application /'? –

+0

mon application complète est enregistrée sous '/ path/to/mon/application /' avec tous ses atouts et c'est php. Le chargement des assets et l'exécution du php fonctionnent exactement comme prévu, mais pour une raison quelconque, je ne peux pas passer les paramètres $ _GET au fastcgi –

+0

Le problème est 'alias' et' try_files'.Vous voulez exécuter votre application sous l'URI '/ app', les choses seraient ** très ** simples si'/path/to/mon/application/'se terminait par'/app' (le même nom de sous-répertoire que l'URI) . –

Répondre

0

Vous avez installé une application sous /path/to/my/app2/public et souhaitez y accéder à l'aide de l'URI /app. En supposant que nous puissions utiliser /app2/ comme un URI interne (qui n'entrera pas en collision avec d'autres URI publics desservis par ce serveur - mais qui ne sera pas vu par vos clients).

Vous avez un fichier PHP.

location ^~ /app { 
    rewrite ^/app(.*)$ /app2/public$1 last; 
}   

location ^~ /app2/ { 
    internal; 

    root /path/to/my; 
    index index.php; 

    try_files $uri $uri/ /app2/public/index.php$is_args$args; 

    location ~ \.php$ { 
     include fastcgi_params; 
     fastcgi_pass 127.0.0.1:9000; 
     fastcgi_param SCRIPT_FILENAME /path/to/my/app2/public/index.php; 
    } 
} 

Le premier bloc de localisation modifie simplement l'URI interne pour correspondre à la racine du document (afin que nous puissions utiliser la racine au lieu d'alias). Le deuxième bloc d'emplacement sert le contenu statique. Le troisième bloc d'emplacement appelle index.php.

Comment index.php obtient la chaîne de requête dépend du programme. Il utilisera l'un des paramètres définis dans fastcgi_params. Habituellement, soit REQUEST_URI, soit QUERY_STRING. Dans les deux cas, les deux variables doivent être conservées avec la configuration ci-dessus.

Le modificateur ^~ garantit que ces blocs d'emplacement ont priorité sur les autres blocs d'emplacement d'expression régulière (le cas échéant). Voir this document pour plus de détails.