GET vs. POST

HTTP POSTER les demandes fournissent des données supplémentaires du client (navigateur) au serveur dans le corps du message. En revanche, OBTENIR les demandes incluent toutes les données requises dans l'URL. Les formulaires HTML peuvent utiliser l’une ou l’autre des méthodes en spécifiant method = "POST" ou method = "GET" (par défaut) dans le élément. La méthode spécifiée détermine le mode de soumission des données de formulaire au serveur. Lorsque la méthode est GET, toutes les données de formulaire sont codées dans l’URL, ajoutées au fichier. action URL 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

OBTENIR	POSTER

L'histoire	Les paramètres restent dans l'historique du navigateur car ils font partie de l'URL	Les paramètres ne sont pas enregistrés dans l'historique du navigateur..
Favoris	Peut être marqué.	Ne peut être marqué.
Bouton Retour / comportement de re-soumission	Les requêtes GET sont ré-exécutées mais ne peuvent pas être soumises au serveur si le code HTML est stocké dans la mémoire cache du navigateur..	Le navigateur prévient généralement l'utilisateur que les données devront être soumises à nouveau..
Type de codage (attribut enctype)	application / x-www-form-urlencoded	multipart / form-data ou application / x-www-form-urlencoded Utilisez le codage en plusieurs parties pour les données binaires.
Paramètres	peut envoyer mais les données de paramètre sont limitées à ce que nous pouvons fourrer dans la ligne de requête (URL). Plus sûr d'utiliser moins de 2 Ko de paramètres, certains serveurs traitent jusqu'à 64 Ko	Peut envoyer des paramètres, y compris le téléchargement de fichiers, au serveur.
Piraté	Plus facile à pirater pour les script kiddies	Plus difficile à pirater
Restrictions sur le type de données de formulaire	Oui, 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. Donc, il est enregistré dans l'historique du navigateur et les journaux du serveur en texte brut.	Le 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 de formulaire	Oui, puisque les données de formulaire sont dans l'URL et que la longueur de l'URL est limitée. La longueur maximale d'une URL sécurisée est souvent de 2 048 caractères, mais elle varie selon le navigateur et le serveur Web..	Pas de restrictions
Utilisabilité	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 tout le monde (elle sera affichée dans la barre d'adresse du navigateur) et limite la quantité d'informations à envoyer..	Les variables de méthode POST ne sont pas affichées dans l'URL.
Mis en cache	Peut être mis en cache	Non mis en cache

Contenu: GET vs POST

1 Différences dans la soumission du formulaire
- 1.1 Avantages et inconvénients
2 différences dans le traitement côté serveur
3 Usage recommandé
4 Qu'en est-il de HTTPS?
5 références

Différences dans la soumission du formulaire

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

Pour la soumission de formulaire avec METHOD = "GET", le navigateur construit une URL en prenant la valeur de action attribut, ajout d'un ? puis ajoutez le jeu de données de 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 parties et reconnaît un hôte, puis envoie à cet hôte une demande GET avec le reste de l'URL en tant qu'argument. Le serveur prend à partir de là. Notez que ce processus signifie que les données de formulaire sont limitées aux codes ASCII. Un soin particulier doit être apporté à l'encodage et au décodage des autres types de caractères lors de leur passage à travers l'URL au format ASCII.

La soumission d’un formulaire avec METHOD = "POST" entraîne l’envoi d’une requête POST à l’aide de la valeur de action attribut et un message créé en fonction du type de contenu spécifié par le enctype attribut.

Avantages et inconvénients

Les données de formulaire étant envoyées avec l’URL lorsque OBTENIR est utilisé --

Les données de formulaire sont limitées aux codes ASCII. Un soin particulier doit être apporté à l'encodage et au décodage des autres types de caractères lors de leur transmission via l'URL au format ASCII. D'autre part, les données binaires, images et autres fichiers peuvent tous être soumis via METHOD = "POST"
Toutes les données de formulaire renseignées 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 font OBTENIR Moins sécurisé.
Cependant, l'un des avantages de l'envoi des données de formulaire dans l'URL est que vous pouvez marquer les URL et les utiliser directement, sans passer par le processus de remplissage du formulaire..
Le nombre de données de formulaire pouvant être envoyées est limité, 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 d'URL.^[1] Bien sûr, les pirates informatiques ou les développeurs Web expérimentés peuvent révéler de telles vulnérabilités même si POST est utilisé. c'est juste un peu plus dur. 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 directes aux objets non sécurisées..

Différences dans le traitement côté serveur

En principe, le traitement des données de formulaire soumises dépend du fait qu’elles sont envoyées 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, en règle générale, le changement de METHOD 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 OBTENIR est utilisé. Mais quand POSTER est utilisé, les données de 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.

Usage recommandé

GET est recommandé lors de la soumission de formulaires "idempotents", c'est-à-dire 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 requête unique. Si des mises à jour de la 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, il sait qu'il est prudent de réessayer automatiquement de le soumettre en cas d'erreur réseau. Pour les formulaires qui utilisent HTTP POST, il peut s'avérer dangereux de réessayer. Le navigateur demande d'abord à l'utilisateur de confirmer.

Une requête "GET" peut souvent être mise en mémoire 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é, en particulier si les chaînes de requête sont simples, car les caches peuvent servir aux requêtes les plus fréquentes..

Dans certains cas, en utilisant POSTER est recommandé même pour les requêtes idempotentes:

Si les données de formulaire contiennent des caractères non-ASCII (comme les caractères accentués), puis METHOD = "GET" est en principe inapplicable, bien que cela puisse fonctionner dans la pratique (principalement pour les caractères ISO Latin 1).
Si le jeu de données est volumineux - dire, des centaines de personnages - alors METHOD = "GET" peut causer des problèmes pratiques avec des implémentations qui ne peuvent pas gérer des URL aussi longues.
Vous voudrez peut-être éviter METHOD = "GET" afin de rendre moins visible pour les utilisateurs le fonctionnement du formulaire, notamment 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 cachés avec METHOD = "POST", ils apparaîtront toujours dans le code source HTML.

Qu'en est-il de HTTPS?

Mis à jour le 15 mai 2015: spécifiquement avec HTTPS (HTTP sur TLS / SSL), le POST offre-t-il plus de sécurité que GET??

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

 OBTENIR https://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 mot de passe sont incluses dans les variables POST, est-ce que cela sera plus sécurisé dans le cas de connexions HTTPS??

La réponse est non. Si vous faites une telle requête GET, l'attaquant surveillant votre trafic Web ne connaîtra que les informations suivantes:

Le fait que vous ayez établi une connexion HTTPS
Le nom d'hôte - www.example.com
La longueur totale de la demande
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 chaîne de requête - est protégée (chiffrée) tant qu’elle est "sur le fil", c’est-à-dire en transit vers le serveur de destination. La situation est exactement la même pour les demandes POST.

Bien entendu, les serveurs Web ont tendance à consigner l’URL complète en texte brut dans leurs journaux d’accès; Il est donc déconseillé d’envoyer des informations sensibles via GET. Ceci s'applique indépendamment du fait que HTTP ou HTTPS soit utilisé.

Références

wikipedia: POST (HTTP)
Méthodes de demande HTTP
HTTP Post - W3.org
HTTP Obtenir - W3.org
HTTPS masque-t-il les URL en cours d'accès?? - Stack Exchange

La technologie