POST (HTTP) - POST (HTTP)

Cet article concerne la méthode HTTP. Il ne doit pas être confondu avec l' autotest à la mise sous tension .
HTTP
Méthodes de demande
Champs d'en-tête
Codes d'état de réponse
Méthodes de contrôle d'accès de sécurité
Vulnérabilités de sécurité

En informatique , POST est une méthode de requête prise en charge par HTTP utilisée par le World Wide Web . De par sa conception, la méthode de requête POST demande qu'un serveur Web accepte les données contenues dans le corps du message de requête, très probablement pour les stocker. Il est souvent utilisé lors du téléchargement d'un fichier ou lors de la soumission d'un formulaire Web rempli .

En revanche, la méthode de requête HTTP GET récupère les informations du serveur. Dans le cadre d'une requête GET, certaines données peuvent être transmises dans la chaîne de requête de l'URL , en spécifiant (par exemple) les termes de recherche, les plages de dates ou d'autres informations qui définissent la requête.

Dans le cadre d'une requête POST, une quantité arbitraire de données de tout type peut être envoyée au serveur dans le corps du message de requête. Un champ d' en- tête dans la requête POST indique généralement le type de média Internet du corps du message.

Données de publication

Le World Wide Web et HTTP sont basés sur un certain nombre de méthodes de requête ou « verbes », y compris POST et GET ainsi que PUT, DELETE et plusieurs autres. Les navigateurs Web n'utilisent normalement que GET et POST, mais les applications en ligne RESTful utilisent de nombreux autres. La place de POST dans la gamme des méthodes HTTP est d'envoyer une représentation d'une nouvelle entité de données au serveur afin qu'elle soit stockée en tant que nouveau subordonné de la ressource identifiée par l' URI . Par exemple, pour l'URI http://example.com/customers, les requêtes POST peuvent être censées représenter de nouveaux clients, chacun incluant leur nom, adresse, coordonnées, etc. Les premiers concepteurs de sites Web se sont éloignés de ce concept original de deux manières importantes. Premièrement, il n'y a aucune raison technique pour qu'un URI décrive textuellement la ressource Web subordonnée à laquelle les données POST seront stockées. En fait, à moins qu'un effort ne soit fait, la dernière partie d'un URI décrira plus probablement la page de traitement de l'application Web et sa technologie, telle que . Deuxièmement, étant donné la limitation naturelle de la plupart des navigateurs Web à utiliser uniquement GET ou POST, les concepteurs ont ressenti le besoin de réutiliser POST pour effectuer de nombreuses autres tâches de soumission et de gestion des données, y compris la modification des enregistrements existants et leur suppression. http://example.com/applicationform.php

Les efforts de certains auteurs influents pour remédier au premier point ont commencé dès 1998. Les frameworks d'applications Web tels que Ruby on Rails et d'autres permettent aux concepteurs de fournir plus facilement à leurs utilisateurs des URL sémantiques . En ce qui concerne le deuxième point, il est possible d'utiliser des scripts côté client ou d'écrire des applications autonomes, d'utiliser les autres méthodes HTTP lorsqu'elles sont pertinentes, mais en dehors de cela, la plupart des formulaires Web qui soumettent ou modifient les données du serveur continuent d'utiliser POST à ​​cette fin.

Cela ne veut pas dire que chaque formulaire Web doit être spécifié method="post"dans sa balise d'ouverture . De nombreux formulaires sont utilisés pour spécifier plus précisément la récupération des informations du serveur, sans aucune intention de modifier la base de données principale. Les formulaires de recherche, par exemple, sont parfaitement adaptés à avoir method="get"spécifié.

Il y a des moments où HTTP GET est moins adapté, même pour la récupération de données. Par exemple, lorsqu'une grande quantité de données doit être spécifiée dans l'URL. Les navigateurs et les serveurs Web peuvent avoir des limites sur la longueur de l'URL qu'ils traiteront sans troncature ni erreur. Le codage en pourcentage des caractères réservés dans les URL et les chaînes de requête peut augmenter considérablement leur longueur, et tandis que Apache HTTP Server peut gérer jusqu'à 4 000 caractères dans une URL, Microsoft Internet Explorer est limité à 2 048 caractères dans n'importe quelle URL. De même, HTTP GET ne doit pas être utilisé lorsque des informations sensibles, telles que des noms d'utilisateur et des mots de passe, doivent être soumises avec d'autres données pour que la demande soit terminée. Même si HTTPS est utilisé, empêchant les données d'être interceptées en transit, l'historique du navigateur et les journaux du serveur Web contiendront probablement l'URL complète en texte brut, qui peut être exposée si l'un des systèmes est piraté. Dans ces cas, HTTP POST doit être utilisé.

Utilisation pour la soumission de formulaires Web

Lorsqu'un navigateur Web envoie une requête POST à ​​partir d'un élément de formulaire Web , le type de média Internet par défaut est « application/x-www-form-urlencoded ». Il s'agit d'un format pour coder des paires clé-valeur avec éventuellement des clés en double. Chaque paire clé-valeur est séparée par un caractère '&', et chaque clé est séparée de sa valeur par un caractère '='. Les clés et les valeurs sont toutes deux échappées en remplaçant les espaces par le caractère « + », puis en utilisant un codage en pourcentage sur tous les autres caractères non alphanumériques .

Par exemple, les paires clé-valeur 

Name: Gareth Wylie
Age: 24
Formula: a+b == 21

sont codés comme 

Name=Gareth+Wylie&Age=24&Formula=a%2Bb+%3D%3D+21

À partir de HTML 4.0, les formulaires peuvent également soumettre des données en multipart/form-data comme défini dans la RFC 2388 (voir également la RFC 1867 pour une version expérimentale antérieure définie comme une extension de HTML 2.0 et mentionnée dans HTML 3.2).

Le cas particulier d'un POST sur la même page à laquelle appartient le formulaire est connu sous le nom de postback .

Affectant l'état du serveur

Selon RFC 7231, la méthode POST n'est pas idempotent , ce qui signifie que plusieurs requêtes identiques peuvent ne pas avoir le même effet que de transmettre la requête une seule fois. POST est donc adapté aux requêtes qui changent d' état à chaque fois qu'elles sont effectuées, par exemple soumettre un commentaire à un article de blog ou voter dans un sondage en ligne. GET est défini comme nullipotent , sans effets secondaires, et les opérations idempotentes n'ont « aucun effet secondaire sur les deuxièmes ou futures requêtes ». Pour cette raison, les robots d'indexation tels que les indexeurs de moteurs de recherche utilisent normalement les méthodes GET et HEAD exclusivement, pour empêcher leurs requêtes automatisées d'effectuer de telles actions.

Cependant, il y a des raisons pour lesquelles POST est utilisé même pour des requêtes idempotentes, notamment si la requête est très longue. En raison de restrictions sur les URL, la chaîne de requête générée par la méthode GET peut devenir très longue, notamment en raison du pourcentage-encodage .

Les références

Liens externes