Configuration de NGINX en tant que serveur Web

Utilisation de variables

Vous pouvez utiliser des variables dans le fichier de configuration pour que NGINX Plus traite les demandes différemment selon les circonstances définies. Les variables sont des valeurs nommées qui sont calculées lors de l’exécution et sont utilisées comme paramètres de directives. Une variable est indiquée par le signe \ (\) (dollar) au début de son nom. Les variables définissent des informations basées sur l’état de NGINX, telles que les propriétés de la demande en cours de traitement.

Il y a un certain nombre de variables prédéfinies, telles que les HTTP principales variables et vous pouvez définir des variables personnalisées à l’ aide des directives  set, mapet des geo. La plupart des variables sont calculées au moment de l’exécution et contiennent des informations liées à une demande spécifique. Par exemple, $remote_addrcontient l’adresse IP du client et $uricontient la valeur URI actuelle.

Retour des codes d’état spécifiques

Certains URI de sites Web nécessitent le retour immédiat d’une réponse avec une erreur spécifique ou un code de redirection, par exemple lorsqu’une page a été déplacée temporairement ou définitivement. Le moyen le plus simple de le faire est d’utiliser la directive return. Par example:

location  /faux/url  { 
    return  404 ; 
}

Le premier paramètre de returnest un code de réponse. Le second paramètre peut être l’URL d’une redirection (pour les codes 301, 302, 303, et 307) ou le texte pour revenir dans le corps de la réponse. Par example:

location  /définitivement/déplacé/url  { 
    return  301  http://www.example.com/déplacé/ici ; 
}

La directive return peut être incluse dans les contextes locationet server.

Réécriture des URI dans les requêtes

Un URI de demande peut être modifié plusieurs fois pendant le traitement de la demande grâce à l’utilisation de la directive rewrite, qui a un paramètre facultatif et deux paramètres obligatoires. Le premier paramètre (obligatoire) est l’expression régulière à laquelle l’URI de la demande doit correspondre. Le deuxième paramètre est l’URI à remplacer par l’URI correspondant. Le troisième paramètre facultatif est un indicateur qui peut interrompre le traitement d’autres rewritedirectives ou envoyer une redirection (code 301ou 302). Par example:

location  /users/  { 
    rewrite  ^ /users/(.*)$ /show?user=$1  break ; 
}

Comme le montre cet exemple, le deuxième paramètre userscapture via la mise en correspondance d’expressions régulières.

Vous pouvez inclure plusieurs directives rewrite dans les contextes serveret location. NGINX Plus exécute les directives une par une dans leur ordre d’apparition. Les directives rewrite dans un contexte server sont exécutées une fois lorsque ce contexte est sélectionné.

Une fois que NGINX a traité un ensemble d’instructions de réécriture, il sélectionne un contexte location en fonction du nouvel URI. Si l’emplacement sélectionné contient des directives rewrite, elles sont exécutées à leur tour. Si l’URI correspond à l’un de ceux-ci, une recherche du nouvel emplacement démarre après le traitement rewrite de toutes les directives définies .

L’exemple suivant montre des directives rewrite en combinaison avec une directive return.

server {
    #...
    rewrite ^(/download/.*)/media/(\w+)\.?.*$ $1/mp3/$2.mp3 last;
    rewrite ^(/download/.*)/audio/(\w+)\.?.*$ $1/mp3/$2.ra  last;
    return  403;
    #...
}

Cet exemple de configuration fait la distinction entre deux ensembles d’URI. Les URI tels que /download/some/media/file sont modifiés en /download/some/mp3/file.mp3 . En raison de l’indicateur last, les directives suivantes (la deuxième rewriteet la directivereturn) sont ignorées mais NGINX Plus continue de traiter la requête, qui a maintenant un URI différent. De même, les URI tels que / download / some / audio / file sont remplacés par /download/some/mp3/file.ra . Si un URI ne correspond à aucune rewritedirective, NGINX Plus renvoie le 403code d’erreur au client.

Deux paramètres interrompent le traitement des rewritedirectives:

• last– Arrête l’exécution des directive rewrite dans le contexte actuel serverou location, mais NGINX Plus recherche les emplacements qui correspondent à l’URI réécrit, et toutes les directive rewrite du nouvel emplacement sont appliquées (ce qui signifie que l’URI peut être à nouveau modifiée).
• break– Comme la directive break, arrête le traitement des directive rewrite dans le contexte actuel et annule la recherche d’emplacements qui correspondent au nouvel URI. Les directives rewrite du nouvel emplacement ne sont pas exécutées.

Réécriture des réponses HTTP

Parfois, vous devez rewrite ou modifier le contenu d’une réponse HTTP, en remplaçant une chaîne par une autre. Vous pouvez utiliser la directive sub_filter pour définir la réécriture à appliquer. La directive prend en charge les variables et les chaînes de substitutions, ce qui rend possible des modifications plus complexes.

Par exemple, vous pouvez modifier les liens absolus qui font référence à un serveur autre que le proxy:

location / {
    sub_filter      /blog/ /blog-staging/;
    sub_filter_once off;
}

Un autre exemple modifie le schéma de http://à https://et remplace l’ localhostadresse par le nom d’hôte du champ d’en-tête de la demande. La directive sub_filter_once indique à NGINX d’appliquer les directives sub_filter consécutivement dans un emplacement:

location / {
    sub_filter     'href="http://127.0.0.1:8080/'%20%20%20%20<span%20class="s">'href="https://<span%20class="nv">$host/';
    sub_filter     'img src="http://127.0.0.1:8080/'%20<span%20class="s">'img src="https://<span%20class="nv">$host/';
    sub_filter_once on;
}

Notez que la partie de la réponse déjà modifiée par le sub_filtern’est pas remplacée à nouveau si une autre sub_filtercorrespondance se produit.

Traitement des erreurs

Avec la directive error_page, vous pouvez configurer NGINX Plus pour renvoyer une page personnalisée avec un code d’erreur, remplacer un code d’erreur différent dans la réponse ou rediriger le navigateur vers un autre URI. Dans l’exemple suivant, la directive error_page spécifie la page ( /404.html ) à renvoyer avec le 404code d’erreur.

error_page  404  /404.html ;

Notez que cette directive ne signifie pas que l’erreur est renvoyée immédiatement (la directive return le fait), mais spécifie simplement comment traiter les erreurs lorsqu’elles se produisent. Le code d’erreur peut provenir d’un serveur mandaté ou se produire lors du traitement par NGINX Plus (par exemple, les 404résultats lorsque NGINX Plus ne trouve pas le fichier demandé par le client).

Dans l’exemple suivant, lorsque NGINX Plus ne parvient pas à trouver une page, il remplace le code 301par du code 404et redirige le client vers http: /example.com/new/path.html . Cette configuration est utile lorsque les clients essaient toujours d’accéder à une page à son ancien URI. Le 301code informe le navigateur que la page a été déplacée de façon permanente et qu’il doit remplacer l’ancienne adresse par la nouvelle automatiquement lors du retour.

location /old/path.html {
    error_page 404 =301 http:/example.com/new/path.html;
}

La configuration suivante est un exemple de transmission d’une requête au back-end lorsqu’un fichier est introuvable. Étant donné qu’aucun code d’état n’est spécifié après le signe égal dans la directive error_page, la réponse au client a le code d’état renvoyé par le serveur mandaté (pas nécessairement 404).

server {
    ...
    location /images/ {
        # Set the root directory to search for the file
        root /data/www;

        # Disable logging of errors related to file existence
        open_file_cache_errors off;

        # Make an internal redirect if the file is not found
        error_page 404 = /fetch$uri;
    }

    location /fetch/ {
        proxy_pass http://backend/;
    }
}

La directive error_page demande à NGINX Plus d’effectuer une redirection interne lorsqu’un fichier n’est pas trouvé. La variable $uri dans le paramètre final de la directive error_page contient l’URI de la requête actuelle, qui est transmise dans la redirection.

Par exemple, si /images/some/file n’est pas trouvé, il est remplacé par /fetch/images/some/file et une nouvelle recherche d’un emplacement démarre. En conséquence, la requête se termine dans le second contexte location et est envoyée par proxy à http://backend/ .

La directive  open_file_cache_errors empêche d’écrire un message d’erreur si un fichier n’est pas trouvé. Ce n’est pas nécessaire ici car les fichiers manquants sont correctement traités.

Références: Original doc : (en) version https://docs.nginx.com/nginx/admin-guide/web-server/