Les objets requête et réponse¶

Attributs¶

Tous les attributs doivent être considérés en lecture seule sauf mention contraire.

HttpRequest.scheme¶

Une chaîne représentant le protocole de la requête (normalement http ou https).

HttpRequest.body¶

Le corps HTTP brut de la requête sous forme de chaine binaire. Cet attribut est utile pour traiter les données de manière différente que ne le fait la gestion habituelle des formulaires HTML : images binaires, contenu XML, etc. Pour ce qui concerne les données de formulaire conventionnelles, utilisez HttpRequest.POST.

Vous pouvez aussi lire le contenu d’un objet HttpRequest en utilisant une interface de type fichier avec HttpRequest.read() ou HttpRequest.readline(). Accéder à l’attribut body après avoir lu le contenu de la requête avec l’une de ces méthodes de flux d’entrée-sortie produira une RawPostDataException.

HttpRequest.path¶

Une chaîne représentant le chemin complet vers la page demandée, sans le protocole ni le domaine.

Exemple : "/musique/groupes/les_beatles/"

HttpRequest.path_info¶

Sous certaines configurations de serveur Web, la partie de l’URL après le nom d’hôte est divisée en une partie « préfixe de script » et une partie « information de chemin ». L’attribut path_info contient toujours la partie information de chemin du chemin, quel que soit le serveur Web utilisé. Il est préférable d’utiliser cet attribut plutôt que path, car cela améliore la portabilité du code entre les serveurs de test et de déploiement.

Par exemple, si le réglage WSGIScriptAlias de votre application est défini à "/minfo", alors path pourrait être "/minfo/musique/groupes/les_beatles/" et path_info serait "/musique/groupes/les_beatles/".

HttpRequest.method¶

Une chaîne correspondant à la méthode HTTP utilisée dans la requête. Elle est toujours en majuscules. Par exemple :

if request.method == 'GET':
    do_something()
elif request.method == 'POST':
    do_something_else()

HttpRequest.encoding¶

Une chaîne représentant le codage actuel utilisé pour décoder les données soumises par formulaire (ou None, ce qui signifie que c’est le réglage DEFAULT_CHARSET qui est utilisé). Vous pouvez redéfinir cet attribut pour modifier le codage utilisé lors de l’accès aux données de formulaires. Toute nouvelle lecture d’attribut (comme l’accès à GET ou à POST) utilisera la nouvelle valeur de encoding. C’est utile lorsque vous savez que les données de formulaire ne sont pas dans le codage DEFAULT_CHARSET.

HttpRequest.content_type¶

Une chaîne représentant le type MIME de la requête, tiré de l’en-tête CONTENT_TYPE.

HttpRequest.content_params¶

Un dictionnaire de paramètres clé/valeur inclus dans l’en-tête CONTENT_TYPE.

HttpRequest.GET¶

Un objet de type dictonnaire contenant tous les paramètres HTTP GET donnés. Voir la documentation QueryDict ci-dessous.

HttpRequest.POST¶

Un objet de type dictonnaire contenant tous les paramètres HTTP POST donnés, pour autant que la requête contienne des données de formulaire. Voir la documentation QueryDict ci-dessous. Si vous avez besoin d’accéder à des données brutes ou non liées à un formulaire provenant de la requête, privilégiez plutôt l’accès par l’attribut HttpRequest.body.

Il est possible qu’une requête arrive par POST avec un dictionnaire POST vide, comme par exemple quand un formulaire est soumis par la méthode HTTP POST mais ne contient pas de données de formulaire. C’est pourquoi il ne faut pas utiliser if request.POST pour savoir si la méthode POST a été utilisée, mais plutôt if request.method == "POST" (voir HttpRequest.method).

POST n’inclut pas d’informations quant à l’envoi de fichiers. Voir FILES.

HttpRequest.COOKIES¶

Un dictionnaire contenant tous les cookies. Les clés et les valeurs sont des chaînes.

HttpRequest.FILES¶

Un objet de type dictionnaire contenant tous les fichiers envoyés. Chaque clé de FILES correspond à l’attribut name de <input type="file" name="">. Chaque valeur de FILES est un objet UploadedFile.

Voir Gestion des fichiers pour plus d’informations.

FILES ne contient des données que si la méthode de requête est POST et que l’élément <form> qui a servi pour envoyer la requête contient enctype="multipart/form-data". Sinon, FILES est un objet de type dictionnaire vide.

HttpRequest.META¶

Un dictionnaire contenant tous les en-têtes HTTP disponibles. Ces en-têtes dépendent du client et du serveur, mais voici tout de même quelques exemples :

• CONTENT_LENGTH – la longueur du corps de la requête (sous forme de chaîne).
• CONTENT_TYPE – le type MIME du corps de la requête.
• HTTP_ACCEPT – types de contenu acceptables pour la réponse.
• HTTP_ACCEPT_ENCODING – codages acceptables pour la réponse.
• HTTP_ACCEPT_LANGUAGE – langues acceptables pour la réponse.
• HTTP_HOST – l’en-tête HTTP Host envoyé par le client.
• HTTP_REFERER – la page d’origine, s’il y en a une.
• HTTP_USER_AGENT – la chaîne « user-agent » du client.
• QUERY_STRING – la chaîne des paramètres de requête, sous forme de chaîne unique (et non analysée).
• REMOTE_ADDR – l’adresse IP du client.
• REMOTE_HOST – le nom d’hôte du client.
• REMOTE_USER – l’utilisateur authentifié par le serveur Web, s’il y en a un.
• REQUEST_METHOD – une chaîne telle que "GET" ou "POST".
• SERVER_NAME – le nom d’hôte du serveur.
• SERVER_PORT – le port du serveur (sous forme de chaîne).

À l’exception de CONTENT_LENGTH et CONTENT_TYPE, tels que présentés ci-dessus, tout en-tête HTTP de la requête est converti en clés META en convertissant tous les caractères en majuscules, remplaçant les tirets par des soulignements et en ajoutant un préfixe HTTP_ au nom. Par exemple, un en-tête nommé X-Bender correspond à la clé META HTTP_X_BENDER.

Notez que runserver ignore tous les en-têtes contenant des soulignements dans leur nom, ce qui fait qu’ils n’apparaîtront pas dans META. Ceci évite la falsification d’en-tête basée sur l’ambiguïté entre les soulignements et les tirets qui sont tous deux normalisés en soulignements dans les variables d’environnement WSGI. Cela correspond au comportement des serveurs Web tels que Nginx et Apache 2.4+.

HttpRequest.headers est une manière plus simple d’accéder à tous les en-têtes préfixés par HTTP, ainsi qu’à CONTENT_LENGTH et CONTENT_TYPE.

HttpRequest.headers¶

New in Django 2.2.

Un objet similaire à un dictionnaire, insensible à la casse, qui donne accès à tous les en-têtes de requête préfixés par HTTP (plus Content-Length et Content-Type).

Le nom de chaque en-tête est mis en forme en casse de titre (par ex. User-Agent) lors de leur affichage. Vous pouvez accéder aux en-têtes de manière insensible à la casse

>>> request.headers
{'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6', ...}

>>> 'User-Agent' in request.headers
True
>>> 'user-agent' in request.headers
True

>>> request.headers['User-Agent']
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)
>>> request.headers['user-agent']
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)

>>> request.headers.get('User-Agent')
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)
>>> request.headers.get('user-agent')
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)

Afin de pouvoir être utilisé par exemple dans les gabarits Django, les en-têtes peuvent aussi être accédés avec une syntaxe par soulignement au lieu de tirets

{{ request.headers.user_agent }}

Changed in Django 3.0:

La prise en charge de l’accès avec la syntaxe par soulignement a été ajoutée.

HttpRequest.resolver_match¶

Une instance de ResolverMatch représentant l’URL résolue. Cet attribut n’est défini qu’après la phase de résolution d’URL, ce qui veut dire qu’il est disponible dans toutes les vues, mais pas dans les intergiciels qui sont exécutés avant la phase de résolution d’URL (l’attribut est cependant disponible dans process_view()).

Attributs définis par le code d’application¶

Django ne définit pas lui-même ces attributs, mais il les exploite s’ils sont définis par une application.

HttpRequest.current_app¶

La balise de gabarit url utilise sa valeur comme paramètre current_app de reverse().

HttpRequest.urlconf¶

Ceci sera utilisé comme configuration d’URL racine pour la requête en cours, écrasant la valeur de ROOT_URLCONF. Voir Processus de traitement des requêtes par Django pour plus de détails.

urlconf peut être défini à None pour annuler tout changement effectué par un intergiciel précédent et revenir à la valeur ROOT_URLCONF de départ.

Attributs définis par l’intergiciel¶

Certains intergiciels inclus dans les applications contribuées de Django définissent des attributs sur la requête. Si vous ne voyez pas un certain attribut dans la requête, vérifiez que la classe d’intergiciel correspondante figure bien dans MIDDLEWARE.

HttpRequest.session¶

Provenant de