('

Extraire l\'URL dans un template Django : request.path vs path_info vs get_full_path vs build_absolute_uri

\n

Il arrive souvent de devoir connaître l\'URL courante dans un template Django.

\n
    \n
  • Activer le menu «\xa0actuel\xa0»
    • \n
  • Rediriger vers la page d\'origine après connexion (paramètre next)
    • \n
  • Générer un lien canonique ou un lien partageable
    • \n
  • Créer un lien qui reproduit exactement la page courante, y compris la chaîne de requête
    • \n
\n

Mais il existe plusieurs attributs et méthodes qui semblent similaires, ce qui peut prêter à confusion. Aujourd\'hui, nous comparons clairement les quatre options suivantes.

\n
    \n
  • request.path
    • \n
  • request.path_info
    • \n
  • request.get_full_path()
    • \n
  • request.build_absolute_uri()
    • \n
\n
\n

Où vient {{ request }}\xa0?

\n

La présence de {{ request }} dans un template indique généralement que le processus de contexte de requête est activé.

\n
    \n
  • django.template.context_processors.request insère l\'objet request dans le contexte du template.
    • \n
  • Ce processeur de contexte est exécuté lorsqu\'il est enregistré dans TEMPLATES → OPTIONS[\'context_processors\'].
    • \n
\n

En pratique, Django inclut par défaut ce processeur, donc la plupart des développeurs n\'ont pas besoin de le configurer manuellement.

\n

L\'objet request lui‑même est une instance de HttpRequest (ou d\'un sous‑type WSGI/ASGI) créé par Django lorsqu\'une requête arrive et est passé à la vue. Cet objet possède des attributs tels que path et path_info.

\n

Django, le magicien, sort un objet request de son chapeau

\n
\n

Résumé en une phrase\xa0: mémorisez ces quatre éléments

\n
    \n
  • path\xa0: «\xa0chemin sans domaine\xa0»
    • \n
  • path_info\xa0: «\xa0chemin réel que l\'application voit (sans le préfixe du script)\xa0»
    • \n
  • get_full_path()\xa0: «\xa0path + chaîne de requête\xa0»
    • \n
  • build_absolute_uri()\xa0: «\xa0schéma + hôte + chemin complet (URL absolue)\xa0»
    • \n
\n

Examinons maintenant chaque option en détail.

\n
\n

1) request.path\xa0: le «\xa0chemin\xa0» sans domaine

\n

request.path renvoie uniquement le chemin de la requête, sans le schéma ni le domaine. Exemple\xa0:

\n
    \n
  • /music/bands/the_beatles/
    • \n
\n

Quand est-ce utile\xa0?

\n
    \n
  • Comparaison simple pour activer un menu
    • \n
\n

django\n {% if request.path == "/settings/" %}active{% endif %}\n* Déterminer la catégorie d\'une page via un préfixe

\n

django\n {% if request.path|slice:":5" == "/api/" %}...{% endif %}

\n
\n

2) request.path_info\xa0: le «\xa0chemin réel\xa0» qui résiste aux changements d\'environnement

\n

Le point clé dans la documentation Django est le suivant\xa0:

\n
    \n
  • Dans certains serveurs, l\'URL est divisée en préfixe du script (SCRIPT_NAME) et path info.
    • \n
  • path_info contient toujours la partie path info, donc il est moins dépendant de l\'environnement.
    • \n
\n

En pratique, si votre application est montée sous un préfixe comme /app (proxy inverse, déploiement sous sous‑chemin), path et path_info peuvent différer.

\n

Quand est-ce utile\xa0?

\n
    \n
  • Environnements de déploiement sous sous‑chemin (ex\xa0: /app/)
    • \n
  • Tests ou serveurs de production où le préfixe peut changer
    • \n
\n
\n

Sur un domaine unique à la racine (/), path et path_info sont identiques, mais la différence devient pertinente lorsqu\'on change d\'environnement.

\n
\n
\n

3) request.get_full_path()\xa0: path + chaîne de requête

\n

get_full_path() renvoie le path suivi de la chaîne de requête. Exemple\xa0:

\n
    \n
  • /music/bands/the_beatles/?print=true
    • \n
\n

Quand est-ce utile\xa0?

\n
    \n
  • Lien de rafraîchissement ou de partage qui reproduit exactement la page courante
    • \n
\n

django\n <a href="{{ request.get_full_path }}">Lien de rafraîchissement</a>\n* Créer un paramètre next après authentification

\n

django\n <a href="/login/?next={{ request.get_full_path|urlencode }}">Connexion</a>

\n
\n

Django propose également get_full_path_info(), qui se base sur path_info. Ce n\'est pas notre sujet aujourd\'hui, mais il est bon de le connaître.

\n
\n
\n

4) request.build_absolute_uri()\xa0: URL absolue complète (schéma + domaine)

\n

build_absolute_uri() construit une URI absolue à partir de la requête courante.

\n

Exemple\xa0:

\n
    \n
  • https://example.com/music/bands/the_beatles/?print=true
    • \n
\n

Quand est-ce utile\xa0?

\n
    \n
  • Partage par e‑mail ou messagerie où le domaine est indispensable
    • \n
  • Balises méta canonique, og:url, etc.
    • \n
  • Fournir une URL de rappel à un système externe
    • \n
\n

Précautions

\n

build_absolute_uri() dépend de l\'information d\'hôte fournie par la requête (get_host()). Cela ne reflète pas toujours l\'URL réelle que l\'utilisateur a saisie. Si vous utilisez un proxy inverse ou avez une logique personnalisée pour get_host(), le résultat peut différer de l\'URL affichée dans le navigateur. Vérifiez toujours votre configuration de déploiement.

\n
\n

Conclusion et résumé

\n
    \n
  • Activer le menu\xa0: request.path
    • \n
  • Environnements sous sous‑chemin\xa0: request.path_info
    • \n
  • Inclure la chaîne de requête\xa0: request.get_full_path()
    • \n
  • Lien complet avec domaine\xa0: request.build_absolute_uri()
    • \n
\n
\n

Articles connexes\xa0:

\n', '/media/editor_temp/6/c112847e-a9ca-4d58-9a3f-076a20bfbef7.png')