Différences dans la soumission de formulaire
La différence fondamentale entre METHODE= »OBTENIR » et METHODE= »POST » c’est qu’ils correspondent à différentes requêtes HTTP, tel que défini dans le HTTP Caractéristiques. 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 le enctype attribut. Pour METHODE= »POST la enctype l’attribut peut être multipart/form-data ou application/x-www-form-urlencoded, alors que pour METHODE= »OBTENIR », seul 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 du action attribut, en ajoutant un ? à celui-ci, puis en ajoutant l’ensemble de données de formulaire (encodé à l’aide du type de contenu application/x-www-form-urlencoded). Le navigateur traite alors cette URL comme s’il suivait un lien (ou comme si l’utilisateur avait tapé directement l’URL). Le navigateur divise l’URL en parties et reconnaît un hôte, puis envoie à cet hôte une requête 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 portée à l’encodage et au décodage 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 du action attribut et un message créé selon le type de contenu spécifié par le enctype attribut.
Avantages et inconvénients
Étant donné que les données de formulaire sont envoyées dans le cadre de l’URL lorsque AVOIR est utilisé —
- Les données de formulaire sont limitées aux codes ASCII. Une attention particulière doit être portée à l’encodage et au décodage d’autres types de caractères lors de leur passage via l’URL au format ASCII. D’autre part, les données binaires, les images et autres fichiers peuvent tous être soumis via METHODE= »POST »
- Toutes les données de 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 font AVOIR Moins sécurisé.
- Cependant, l’un des avantages des données de formulaire envoyées dans le cadre de l’URL est que l’on peut marquer les URL et les utiliser directement et contourner complètement le processus de remplissage du formulaire.
- La quantité de données de formulaire pouvant être envoyée est limitée car Les longueurs d’URL sont limitées.
- 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, des pirates informatiques ou des développeurs Web expérimentés peuvent exposer 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 Références directes d’objets 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 du fait qu’il soit envoyé avec METHODE= »OBTENIR » ou METHODE= »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, lorsque en utilisant l’interface CGI, le script reçoit les données dans une variable d’environnement (QUERYSTRING) lorsque AVOIR est utilisé. Mais quand PUBLIER est utilisé, les données du formulaire sont transmises dans le flux d’entrée standard (standard) et le nombre d’octets à lire est donné par l’en-tête Content-length.
Que se passe-t-il lorsque les variables GET et POST sont en conflit ?
Dans certains langages tels que PHP, les informations des paramètres GET et POST, en plus d’être disponibles séparément, sont également combinées dans une variable de commodité, par exemple, $_REQUEST en PHP. S’il y a un conflit, c’est-à-dire que le même nom de paramètre est utilisé avec des valeurs différentes dans GET et POST, alors le conflit est résolu avec certaines règles. Dans le cas de PHP, la priorité est décidée par le commandes_variables directive de configuration. L’ordre par défaut est EGPCS (environnement, GET, POST, Cookie, Server). Cela signifie que la variable dans $_GET a la priorité sur $_POST, qui à son tour a la priorité sur $_COOKIE.
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, des 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 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.
Du 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 peut réessayer automatiquement la soumission en cas d’erreur réseau. Pour les formulaires qui utilisent HTTP POST, il n’est peut-être pas sûr de réessayer, le navigateur demande donc d’abord à l’utilisateur une confirmation.
Une requête « GET » est souvent cacheable, 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, en utilisant PUBLIER est recommandé même pour les requêtes idempotentes :
- Si les données du formulaire contiennent des caractères non ASCII (comme les caractères accentués), puis METHODE= »OBTENIR » est inapplicable en principe, bien qu’il puisse fonctionner en pratique (principalement pour Caractères ISO Latin 1).
- Si l’ensemble de données de formulaire est volumineux – disons, des centaines de caractères – alors METHODE= »OBTENIR » peut causer des problèmes pratiques avec les implémentations qui ne peuvent pas gérer des URL aussi longues.
- Vous voudrez peut-être éviter METHODE= »OBTENIR » afin de rendre moins visible aux utilisateurs le fonctionnement du formulaire, notamment afin de masquer davantage les champs « cachés » (INPUT TYPE= »HIDDEN ») en n’apparaissant pas dans l’URL. Mais même si vous utilisez des champs masqués avec METHODE= »POST », ils apparaîtront toujours dans le code source HTML.
Qu’en est-il du HTTPS ?
Mis à jour le 15 mai 2015 : 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. Imaginons que vous fassiez une requête GET sur une page Web :
GET 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 user et passwd sont incluses dans les variables POST, cela sera-t-il plus sécurisé dans le cas des connexions HTTPS ?
La réponse est non. Si vous effectuez une telle requête GET, seules les informations suivantes seront connues de l’attaquant surveillant votre trafic Web :
- 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 la chaîne de requête – sont protégés (cryptés) lorsqu’ils sont « over the wire », c’est-à-dire en transit vers le serveur de destination. La situation est exactement la même pour les requêtes POST.
le PUBLIER La méthode conserve cependant un avantage, même dans le cas de HTTPS. Les serveurs Web ont tendance à enregistrer l’intégralité de l’URL demandée en texte clair dans leurs journaux d’accès ; l’envoi d’informations sensibles via GET n’est donc pas une bonne idée. Ceci s’applique indépendamment du fait que HTTP ou HTTPS soit utilisé.
