Réécrire les règles modifier une partie ou la totalité d’une URL. Ceci est fait pour deux raisons. Premièrement, pour informer les clients de la relocalisation des ressources, et deuxièmement, pour contrôler le flux vers Nginx. Les deux méthodes générales largement utilisées pour la réécriture d’URL sont la revenir directive et la récrire directif. Parmi celles-ci, la directive de réécriture est la plus puissante. Voyons pourquoi il en est ainsi, ainsi que comment réécrire les URL.
Une meilleure compréhension de NGINX facilitera le suivi de ce blog.
Directive de retour
Revenir est le moyen le plus simple de réécrire une URL déclarée sur le serveur ou la machine locale.
Retour dans le serveur
Supposons que votre site soit migré vers un nouveau domaine et que toutes les URL existantes soient redirigées ici ; exécutez le code ci-dessous pour diriger toute nouvelle demande vers votre site.
Ceci dirige toutes les demandes qui atteignent www.domaineprécédent.com à www.domainecourant.com. Les www.previousomain.com enverra une erreur « 301 » dès que le code ci-dessus est exécuté et qu’une nouvelle demande d’accès est générée. Les deux variables, $scheme, et $request_uri, obtenir des données à partir de l’URL d’entrée. « Écoutez 80 » indique que le blocage s’applique aux requêtes HTTP et HTTPS.
Retour en local
Si vous souhaitez rediriger des pages à la place d’un domaine complet, vous pouvez utiliser le revenir directive sous le bloc de localisation.
Savoir comment créer les règles de réécriture Nginx peut vous faire économiser beaucoup d’efforts et de temps.
Directive de réécriture
Tout comme le revenir directive, la récrire La directive peut également agir à la fois sur le serveur et en local. Par rapport au revenir directive, la récrire La directive peut gérer des remplacements complexes d’URL. Voici la syntaxe du récrire:
Les regex est une expression régulière qui correspond à l’URI entrant.
Les replacement_url est la chaîne utilisée pour modifier l’URI demandé.
La valeur de la flag décide si une redirection ou un traitement supplémentaire est nécessaire.
Réécriture de page statique
Supposons que vous vouliez rediriger la page https://example.com/tutorial à https://example.com/new_page. La directive sera :
La ligne location = /tutorial définit que toute identification du tutoriel doit être remplacée. Les récrire la commande dit de remplacer la phrase dans les notations ^ et $ par new_page.html puis cassez la commande. La mention ‘?’ est qualifié de modificateur non gourmand, après quoi la recherche de motif est arrêtée.
Réécriture de page dynamique
Pensez à réécrire l’URL https://www.sample.com/user.phpid=11 à https://www.sample.com/user/11. Ici, l’utilisateur=11 doit être remplacé. En utilisant la méthode de réécriture statique, il faudrait écrire la commande de réécriture 10 fois. Au lieu de cela, faisons-le en une seule fois.
La ligne location = /user.php demande à Nginx de vérifier le prefix'/user'. Comme dit précédemment, le Nginx recherchera les phrases entre les notations de début et de fin comme ^ et $ avec le non gourmand ‘?’ modificateur. La phrase dans notre exemple est une gamme d’utilisateurs. Il est mentionné entre crochets comme [0-9]+. La référence arrière dans cette expression est notée entre parenthèses et est désignée par le symbole $1. Ainsi, pour notre exemple, la réécriture se fera automatiquement pour tous les utilisateurs.
Un cas particulier sous la référence dynamique est celui des multiples références arrière.
Maintenant, nous avons discuté de la façon d’écrire les règles de réécriture pour les URL simples et complexes.
Comprendre le fonctionnement détaillé des règles de réécriture à travers quelques exemples manipulant divers scénarios.
Comparaison des directives
Analysons les deux directives en les comparant et découvrons pourquoi la dérivée de réécriture est plus puissante.
Directive de retour
- Il est simple à utiliser et à comprendre.
-
Il peut être utilisé à la fois dans des contextes de serveur et de localisation.
-
Il mentionne explicitement l’URL corrigée ou mise à jour afin que le client puisse les utiliser à l’avenir.
-
Les directives de retour peuvent également inclure plusieurs codes d’erreur.
-
Pour les codes 301, 302, 303 et 307, les paramètres d’URL définissent l’URL de redirection.
return (301 | 302 | 303 | 307) url;
return (1xx | 2xx | 4xx | 5xx) ["text"];
Par exemple, return 401 « Accès refusé car le jeton a expiré ou n’est pas valide » ;
Directive de réécriture
-
Il peut s’adapter à des modifications d’URL plus complexes nécessitant la capture d’éléments sans variables Nginx ou une mise à jour des éléments du chemin.
-
Il peut être utilisé à la fois dans des contextes de serveur et de localisation.
-
La directive rewrite ne peut renvoyer que le code 301 ou 302. Pour accommoder d’autres codes, ajoutez explicitement la directive return après la directive rewrite.
-
Il ne peut pas envoyer les détails de redirection au client.
-
Le traitement de la demande Nginx n’est pas interrompu.
Conclusion
Les revenir et récrire Les directives peuvent être utilisées pour rediriger les URL dans les contextes de serveur et d’emplacement. Bien que la directive return soit beaucoup plus simple, la directive rewrite est largement utilisée car elle peut également gérer des modifications/mises à jour complexes des URL.