GET vs POST

Les requêtes HTTP POST fournissent des données supplémentaires du client (navigateur) au serveur dans le corps du message. En revanche, les demandes GET incluent toutes les données requises dans l'URL. Les formulaires HTML peuvent utiliser l'une ou l'autre méthode en spécifiant method = "POST" ou method = "GET" (par défaut) dans le élément. La méthode spécifiée détermine la manière dont les données du formulaire sont soumises au serveur. Lorsque la méthode est GET, toutes les données du formulaire sont codées dans l'URL, ajoutées à l'URL d' action en tant que paramètres de chaîne de requête. Avec POST, les données de formulaire apparaissent dans le corps du message de la requête HTTP.

Tableau de comparaison

Tableau de comparaison GET versus POST
AVOIR PUBLIER
HistoireLes paramètres restent dans l'historique du navigateur car ils font partie de l'URLLes paramètres ne sont pas enregistrés dans l'historique du navigateur.
FavorisPeut être mis en signet.Ne peut pas être mis en signet.
Bouton RETOUR / comportement de nouvelle soumissionLes demandes GET sont réexécutées mais ne peuvent pas être soumises à nouveau au serveur si le code HTML est stocké dans le cache du navigateur.Le navigateur avertit généralement l'utilisateur que les données devront être soumises à nouveau.
Type d'encodage (attribut enctype)application / x-www-form-urlencodedmultipart / form-data ou application / x-www-form-urlencoded Utilisez le codage en plusieurs parties pour les données binaires.
Paramètrespeut envoyer, mais les données des paramètres sont limitées à ce que nous pouvons insérer dans la ligne de demande (URL). Plus sûr d'utiliser moins de 2 Ko de paramètres, certains serveurs gèrent jusqu'à 64 KoPeut envoyer des paramètres, y compris le téléchargement de fichiers, au serveur.
PiratéPlus facile à pirater pour les script kiddiesPlus difficile à pirater
Restrictions sur le type de données du formulaireOui, seuls les caractères ASCII sont autorisés.Pas de restrictions. Les données binaires sont également autorisées.
SécuritéGET est moins sécurisé que POST car les données envoyées font partie de l'URL. Il est donc enregistré dans l'historique du navigateur et les journaux du serveur en texte clair.POST est un peu plus sûr que GET car les paramètres ne sont pas stockés dans l'historique du navigateur ou dans les journaux du serveur Web.
Restrictions sur la longueur des données du formulaireOui, car les données du formulaire se trouvent dans l'URL et la longueur de l'URL est limitée. Une limite de longueur d'URL sûre est souvent de 2048 caractères, mais varie selon le navigateur et le serveur Web.Pas de restrictions
ConvivialitéLa méthode GET ne doit pas être utilisée lors de l'envoi de mots de passe ou d'autres informations sensibles.Méthode POST utilisée lors de l'envoi de mots de passe ou d'autres informations sensibles.
VisibilitéLa méthode GET est visible par tous (elle sera affichée dans la barre d'adresse du navigateur) et a des limites sur la quantité d'informations à envoyer.Les variables de la méthode POST ne sont pas affichées dans l'URL.
En cachePeut être mis en cacheNon mis en cache

Différences dans la soumission des formulaires

La différence fondamentale entre METHOD = "GET" et METHOD = "POST" est qu'elles correspondent à différentes requêtes HTTP, telles que définies dans les spécifications HTTP. Le processus de soumission pour les deux méthodes commence de la même manière - un ensemble de données de formulaire est construit par le navigateur, puis codé d'une manière spécifiée par l'attribut enctype . Pour METHOD = "POST, l'attribut enctype peut être multipart / form-data ou application / x-www-form-urlencoded, tandis que pour METHOD =" GET ", seul application / x-www-form-urlencoded est autorisé. Ces données de formulaire l'ensemble est ensuite transmis au serveur.

Pour la soumission de formulaire avec METHOD = "GET", le navigateur construit une URL en prenant la valeur de l'attribut action, en ajoutant un ? puis ajoutez l'ensemble de données du formulaire (codé à l'aide du type de contenu application / x-www-form-urlencoded). Le navigateur traite ensuite cette URL comme s'il suivait un lien (ou comme si l'utilisateur avait tapé l'URL directement). Le navigateur divise l'URL en plusieurs parties et reconnaît un hôte, puis envoie à cet hôte une demande GET avec le reste de l'URL comme argument. Le serveur le prend à partir de là. Notez que ce processus signifie que les données du formulaire sont limitées aux codes ASCII. Une attention particulière doit être prise pour encoder et décoder d'autres types de caractères lors de leur passage via l'URL au format ASCII.

La soumission d'un formulaire avec METHOD = "POST" provoque l'envoi d'une requête POST, en utilisant la valeur de l'attribut action et un message créé selon le type de contenu spécifié par l'attribut enctype .

Avantages et inconvénients

Étant donné que les données du formulaire sont envoyées dans le cadre de l'URL lorsque GET est utilisé -

  • Les données du formulaire sont limitées aux codes ASCII. Une attention particulière doit être prise pour encoder et décoder d'autres types de caractères lors de leur passage via l'URL au format ASCII. D'un autre côté, les données binaires, les images et autres fichiers peuvent tous être soumis via METHOD = "POST"
  • Toutes les données du formulaire remplies sont visibles dans l'URL. De plus, il est également stocké dans l'historique / les journaux de navigation Web de l'utilisateur pour le navigateur. Ces problèmes rendent GET moins sûr.
  • Cependant, un avantage des données de formulaire envoyées dans le cadre de l'URL est que l'on peut mettre en signet les URL et les utiliser directement et contourner complètement le processus de remplissage du formulaire.
  • Il existe une limitation sur la quantité de données de formulaire pouvant être envoyées car la longueur des URL est limitée.
  • Les script kiddies peuvent plus facilement exposer les vulnérabilités du système pour le pirater. Par exemple, Citibank a été piraté en modifiant les numéros de compte dans la chaîne URL. [1] Bien sûr, les pirates informatiques ou les développeurs Web expérimentés peuvent exposer ces vulnérabilités même si le POST est utilisé; c'est juste un peu plus difficile. En général, le serveur doit se méfier des données envoyées par le client et se prémunir contre les références d'objet direct non sécurisées.

Différences dans le traitement côté serveur

En principe, le traitement des données d'un formulaire soumis dépend de leur envoi avec METHOD = "GET" ou METHOD = "POST" . Étant donné que les données sont codées de différentes manières, différents mécanismes de décodage sont nécessaires. Ainsi, d'une manière générale, changer la MÉTHODE peut nécessiter un changement dans le script qui traite la soumission. Par exemple, lors de l'utilisation de l'interface CGI, le script reçoit les données dans une variable d'environnement (QUERYSTRING) lorsque GET est utilisé. Mais lorsque POST est utilisé, les données du formulaire sont transmises dans le flux d'entrée standard ( stdin ) et le nombre d'octets à lire est donné par l'en-tête Content-length.

Utilisation recommandée

GET est recommandé lors de la soumission de formulaires "idempotents" - ceux qui ne "modifient pas de manière significative l'état du monde". En d'autres termes, les formulaires qui impliquent uniquement des requêtes de base de données. Une autre perspective est que plusieurs requêtes idempotentes auront le même effet qu'une seule requête. Si des mises à jour de base de données ou d'autres actions telles que le déclenchement d'e-mails sont impliquées, l'utilisation de POST est recommandée.

Sur le blog des développeurs Dropbox:

un navigateur ne sait pas exactement ce que fait un formulaire HTML particulier, mais si le formulaire est soumis via HTTP GET, le navigateur sait qu'il est sûr de retenter automatiquement la soumission s'il y a une erreur de réseau. Pour les formulaires qui utilisent HTTP POST, il peut ne pas être sûr de réessayer, le navigateur demande d'abord à l'utilisateur une confirmation.

Une requête "GET" peut souvent être mise en cache, alors qu'une requête "POST" peut difficilement l'être. Pour les systèmes de requête, cela peut avoir un impact considérable sur l'efficacité, surtout si les chaînes de requête sont simples, car les caches peuvent servir les requêtes les plus fréquentes.

Dans certains cas, l'utilisation de POST est recommandée même pour les requêtes idempotentes:

  • Si les données du formulaire contiennent des caractères non ASCII (tels que des caractères accentués), alors METHOD = "GET" est inapplicable en principe, bien qu'il puisse fonctionner dans la pratique (principalement pour les caractères ISO Latin 1).
  • Si l'ensemble de données du formulaire est volumineux - par exemple, des centaines de caractères - alors METHOD = "GET" peut entraîner des problèmes pratiques avec les implémentations qui ne peuvent pas gérer ces URL longues.
  • Vous souhaiterez peut-être éviter METHOD = "GET" afin de rendre moins visible aux utilisateurs le fonctionnement du formulaire, en particulier afin de rendre les champs "masqués" (INPUT TYPE = "HIDDEN") plus masqués en n'apparaissant pas dans l'URL. Mais même si vous utilisez des champs masqués avec METHOD = "POST", ils apparaîtront toujours dans le code source HTML.

Qu'en est-il du HTTPS?

Mise à jour le 15 mai 2015: en particulier lors de l'utilisation de HTTPS (HTTP sur TLS / SSL), POST offre-t-il plus de sécurité que GET?

C'est une question intéressante. Supposons que vous fassiez une demande GET sur une page Web:

 GET //www.example.com/login.php?user=mickey&passwd=mini 

En supposant que votre connexion Internet soit surveillée, quelles informations sur cette demande seront disponibles pour le snooper? Si POST est utilisé à la place et que les données utilisateur et passwd sont incluses dans les variables POST, cela sera-t-il plus sûr dans le cas des connexions HTTPS?

La réponse est non. Si vous faites une telle demande GET, seules les informations suivantes seront connues de l'attaquant surveillant votre trafic Web:

  1. Le fait que vous ayez établi une connexion HTTPS
  2. Le nom d'hôte - www.example.com
  3. La durée totale de la demande
  4. La longueur de la réponse

La partie chemin de l'URL - c'est-à-dire la page réelle demandée, ainsi que les paramètres de la chaîne de requête - sont protégés (cryptés) pendant qu'ils sont "sur le fil", c'est-à-dire en transit sur le chemin du serveur de destination. La situation est exactement la même pour les requêtes POST.

Bien sûr, les serveurs Web ont tendance à enregistrer l'intégralité de l'URL en texte brut dans leurs journaux d'accès; envoyer des informations sensibles via GET n'est donc pas une bonne idée. Cela s'applique indépendamment du fait que HTTP ou HTTPS soit utilisé.

Articles Connexes