Discussion :

[Invité]

Bonjour,

J'aimerais bien connaître la différence entre les méthodes POST et GET du protocole http. Ce que j'en sais pour le moment c'est qu'avec la méthode GET on envoie des paramètres à l'intérieur de l'url (après le ?) et avec POST les paramètres sont "cachés" dans la requête http.

Ce que je voudrais savoir c'est s'il y a d'autres différences entre ces deux méthodes. Je m'y connais pas trop en requête http alors si quelqu'un en sait plus long ce serait gentil de m'éclairer ou de me rediriger vers un cours sur le protocole http.

[_Mac_]

http://www.themanualpage.org/http/

GET : effectivement, tout passe dans l'URL. POST, y a un corps de requête, donc un en-tête Content-Lenght entre autres qui n'apparaît pas autrement dans les requêtes GET.

Qu'est-ce qui t'intéresse comme point en particulier ?

[Invité]

J'ai lu les cours qu'il y avait dans le lien que tu m'as passé et ça a éclairci pas mal de points.
Pour le méthode POST, si j'ai bien compris, c'est la "seule" manière (sans compter le GET quand l'url est suivie de ?) d'envoyer des information (dont des fichiers ) au serveur.

J'ai quand même quelques questions :
Est-ce que la requête HTTP, dans son paquet TCP, est envoyée sous forme de texte ou sous forme de flux binaire (ça sert sans doute pas à grand chose de savoir ça mais c'est juste pour ma culture générale).

Quel est l'intérêt de laisser la possibilité au client d'envoyer des informations avec la méthode GET (après le ?) vu que la méthode POST est là pour ça ?

Apparemment on peut envoyer des fichiers via la méthode POST. Quel genre d'applications cela peut-il avoir ?

[_Mac_]

Pour le méthode POST, si j'ai bien compris, c'est la "seule" manière (sans compter le GET quand l'url est suivie de ?) d'envoyer des information (dont des fichiers ) au serveur.

Stricto senso, non, il y a PUT aussi mais cette méthode n'est jamais utilisé sur le Web "classique". On l'utilise plutôt en WebDAV et en REST.

Est-ce que la requête HTTP, dans son paquet TCP, est envoyée sous forme de texte ou sous forme de flux binaire (ça sert sans doute pas à grand chose de savoir ça mais c'est juste pour ma culture générale).

A ton avis, si on peut faire un telnet sur le port 80 et taper les requêtes HTTP avec ses petits doigts boudinés ? HTTP est comme SMTP : c'est un protocole humainement compréhensible. Tu peux faire un essai tout simple : ouvre un interpréteur de commande et exécute la commande "telnet www.google.fr 80" (sans les ", tu l'auras deviné). Quand le telnet accroche, copie le texte suivant et colle-le dans ton telnet :

GET / HTTP/1.1
Host: www.google.fr

N'oublie pas les sauts de ligne à la fin (s'il se passe rien, tape sur Entrée 2/3 fois). Et là, tu verras la réponse de Google, en clair.

C'est ça que j'aime bien avec ce protocole, c'est qu'il est hyper simple et hyper clair, facile à mettre en pratique et à déboguer.

Quel est l'intérêt de laisser la possibilité au client d'envoyer des informations avec la méthode GET (après le ?) vu que la méthode POST est là pour ça ?

C'est assez variable, en fait. Déjà, il y a une considération de taille : on ne peut utiliser GET pour envoyer un fichier par exemple ou remplir un formulaire trop gros. Certes, il n'y a plus vraiment de limitation en terme de longueur d'URL mais on essaie quand même généralement de pas les faire trop grandes.

Souvent, on va utiliser POST quand il y a des données sensibles : si on utilise GET, ces données vont apparaître dans l'URL et donc vont potentiellement être visibles et "bookmarkables", ce qu'on ne veut pas forcément. L'inverse est aussi vrai : GET est adapté pour les petits formulaires pour lesquels on veut autoriser les bookmarks. Ce caractère non bookmarkable de POST fait aussi que les navigateurs ont un comportement particulier quand tu utilises les boutons Suivant et Précédent : quand tu repasses par un écran résultant d'un POST, tu as un message te demandant si tu veux resoumettre les données. En fait, l'idée implicite véhiculée par GET c'est le côté persistant ou "sans état" des URL : une URL est idempotente, c'est à dire qu'on s'attend logiquement à ce qu'il se passe toujours la même chose quand on l'appelle. Mais on sait toi et moi que ce n'est pas toujours le cas, mais c'est néanmoins l'idée générale.

Si tu fais des liens (<a href="...?param=valeur">) comme par exemple les liens qui te permettent de passer d'un forum à un autre, tu passes nécessairement et implicitement par GET. Tu ne peux pas utiliser POST sur un lien sauf à construire un formulaire "caché" et à utiliser du JavaScript pour le soumettre au clic sur le lien.

Apparemment on peut envoyer des fichiers via la méthode POST. Quel genre d'applications cela peut-il avoir ?

Il y a plus de cas où on veut autoriser l'envoi de fichiers sur un serveur. Par exemple, le bouton "Gérer les pièces jointes" quand tu écris un message sur le forum Ou encore quand tu utilises un webmail pour ajouter une pièce jointe. Ou pour envoyer ta photo sur ton profil Facebook.

[Invité]

Merci beaucoup pour toutes ces réponses.
Ce soir je me coucherai en ayant la satisfaction de posséder une compréhension plus profonde du protocole http qu'en me levant. Une grande source de satisfaction.

Je mets la balise "résolu" étant donné que j'ai obtenu la réponse à mes questions.

[_Mac_]

Si t'as d'autres questions, n'hésite pas