Méthodes de passages de paramètres dans une URL
Le mode de passage des paramètres par un formulaire est défini par l'attribut method de la balise <form> ci-dessous :
<form method="........" action="fichier.php">
ICI LES ELEMENTS DU FORMULAIRE
</form>
Il y a 2 méthodes : GET et POST que nous voyons dans le détail ci-dessous.
Rappel :
On rappelle les différentes syntaxes associées aux formulaires disponibles sur cette page.
Définition : Méthode GET
Si l'attribut de method est absent ou que sa valeur est GET alors les paramètres du formulaire sont passés au serveur via l'URL, en suivant la syntaxe précédente :
protocole://nom_ou_adresse_IP:port/fichier.php?paramètre1=valeur1&...¶mètreN=valeurN
Définition : Méthode POST
Si l'attribut de method est POST, alors les paramètres sont passés au serveur de manière différente. Le navigateur Web forme bien la chaîne de caractères paramètre1=valeur1&...¶mètreN=valeurN. Cependant, il envoie un message HTTP commençant par POST. Les paramètres sont alors placés dans le corps de la requête HTTP.
Exemple :
Voici un exemple qui vous permettra de mieux comprendre.
Compléter les formulaires et faire le nécessaire pour bien comprendre comment sont envoyés, au serveur, les paramètres du formulaire.
En savoir plus sur la méthode GET
Avantages
L'intérêt de la méthode GET est que toute l'information nécessaire au serveur est contenue dans l'URL.
En prenant comme exemple le site web data.gouv.fr, plate-forme des données publiques (on parle d'OpenData[1]) déposées par l'État, les collectivités et les organismes publics, on peut voir que ce site dispose d'un champ de recherche ; ainsi, si on veut trouver toutes les données liées à l'informatique, on peut y accéder directement avec l'URL suivante :
Ainsi, on peut stocker cette adresse en marque-pages dans le navigateur mais aussi ajouté cette URL dans une page Web. Tous les nouveaux jeux de données liés à l'informatique seront ajoutés automatiquement.
Limitations
On peut avoir dans un formulaire une entrée de type <textarea>, avec donc du texte très long... Aussi, on peut donc avoir des serveurs qui répondent avec un code d'erreur 414 (URL too long), même si on peut avoir jusqu'à quelques milliers d'octets.
Au niveau sécurité, on peut avoir un vrai problème concernant les mots de passe qui seraient affichés en clair dans l'URL ! Ce qui est évidemment pas recommandé !
En savoir plus sur la méthode POST
Les caractéristiques de la méthode POST sont exactement inverses à la méthode GET.
On ne peut pas sauvegarder une URL pour la ré-exploiter puisque les paramètres transitent dans le corps de la requête HTTP.
Fondamental :
Le protocole HTTP demande l'utilisation de la méthode POST pour toute requête effectuant des mises à jour côté serveur.
Imaginons un service de réservation de billets, on doit utiliser POST car à chaque billet vendu, on doit décrémenter le stock de billets (mise à jour côté serveur). Si un problème de connexion réseau survient, la page de confirmation peut ne pas se charger. Le navigateur Web continue d'attendre le résultat... et on serait tenté de recharger la page, envoyant une nouvelle fois notre requête et on achèterait donc à nouveau des billets...
Firefox se charge d'en avertir l'internaute avec le message suivant :
Pour afficher cette page, les informations précédemment transmises par Firefox doivent être renvoyées. Ceci répétera toute action (telle qu'une recherche ou un ordre d'achat) entreprise précédemment.
Mais, il est important de bien comprendre que lorsqu'on soumet un mot de passe dans un formulaire, on doit IMPERATIVEMENT utiliser la méthode POST, mais ceci n'est pas SUFFISANT, car le mot de passe circulera en clair dans la requête HTTP (c'est vérifiable en analysant des trames TCP, avec des logiciels du type WireShark). Pour cela, il faudra chiffrer les échanges avec HTTPS, vu précédemment. Les navigateurs modernes nous alertent s'il y a un champ de type password SANS HTTPS.