Formulaires Web : comprendre GET et POST

Des champs nommés deviennent des paramètres

Un formulaire possède notamment une destination, indiquée par action, et une méthode, indiquée par method. Un champ doit avoir un nom pour participer normalement à l’envoi des valeurs correspondantes. L’étiquette visible aide l’utilisateur, mais ce n’est pas elle qui détermine le nom du paramètre transmis. Un champ name = "ville" contenant Lyon produit ainsi une association ville=Lyon. Certains contrôles ont des règles particulières : une case à cocher non cochée n’envoie généralement pas son paramètre. Pour analyser le résultat, il faut donc examiner la structure du formulaire et son état au moment de la soumission.

Voici un formulaire pédagogique complet pour analyser une soumission. La destination /recherche représente un service d’exemple ; le code décrit la demande, mais sa réponse doit être programmée sur le serveur concerné.

<form action="/recherche" method="get">
  <label for="notion">Notion recherchée</label>
  <input id="notion" name="notion" value="arbre" required>
  <label for="niveau">Niveau</label>
  <select id="niveau" name="niveau">
    <option value="premiere">Première</option>
    <option value="terminale">Terminale</option>
  </select>
  <button type="submit">Rechercher</button>
</form>

L’identifiant relie un champ à son étiquette ou à un script ; le nom sert de clé dans les données envoyées. Ces attributs peuvent avoir la même valeur par commodité, mais ils ne jouent pas le même rôle. Un nom manquant peut donc laisser un champ visible sans paramètre transmis.

GET place les paramètres dans la cible de la requête

Un formulaire GET encode les paramètres dans la partie de requête de l’URL, après le point d’interrogation. Une recherche peut produire /recherche?notion=graphe&niveau=terminale. Cette adresse peut être copiée, partagée ou ajoutée à un favori pour retrouver le même résultat, si le site respecte ce fonctionnement. GET est destiné à demander une représentation sans provoquer une modification applicative attendue. Une suppression de données ne devrait donc pas être déclenchée simplement par l’ouverture d’un lien GET. Cette distinction concerne le sens de la demande, pas seulement l’emplacement du texte.

Les caractères spéciaux doivent être encodés pour ne pas être confondus avec les séparateurs de l’URL. Un espace peut notamment apparaître sous une forme encodée. Cette transformation rend le message transportable ; elle n’est pas un chiffrement et permet de retrouver les caractères d’origine.

POST transmet habituellement les paramètres dans le corps

Un formulaire POST envoie ses données dans le corps de la requête selon l’encodage choisi, au lieu de les ajouter à l’URL de la même manière. Il convient notamment aux soumissions que le serveur doit traiter et qui peuvent modifier son état. POST ne signifie pas « chiffré » : sans HTTPS, le contenu peut circuler sans la protection cryptographique attendue. Même avec HTTPS, le serveur reçoit les données lisibles. L’URL plus courte ne prouve donc pas à elle seule que l’application ne conserve rien ni que les informations sont accessibles uniquement à l’utilisateur.

Un corps de requête reste observable par le serveur destinataire et par les outils du navigateur. Le choisir peut répondre au sens de l’action et au format des données. La confidentialité du transport dépend séparément du canal HTTPS.

Valider aux bons endroits et vérifier la réponse

Les contrôles du navigateur, comme required ou un type de champ, améliorent la saisie. Ils ne dispensent pas le serveur de vérifier les valeurs, car une demande peut être construite en dehors de la page. Le serveur doit ensuite répondre de manière compréhensible : succès, erreur de champ, absence de ressource ou autre situation. Dans une analyse, suivez une valeur depuis le champ jusqu’au paramètre reçu, puis jusqu’à son utilisation. N’envoyez jamais de mots de passe ou d’informations sensibles dans une URL partageable ; choisissez aussi une collecte proportionnée au besoin réel.

Le serveur doit prévoir les paramètres absents, répétés ou invalides selon le contrat du service. Un formulaire donné produit une forme habituelle de demande, mais il ne limite pas toutes les demandes possibles. Les décisions essentielles doivent donc être vérifiées lors de leur réception.

Suivre une valeur avec un espace et un accent

Une recherche sur « arbre binaire » en GET produit une association dont le nom est notion et la valeur le texte complet. L’espace doit être représenté dans l’URL sans devenir un séparateur de paramètres. Dans le modèle de l’atelier, il apparaît sous la forme %20. Pour « réseau », les octets UTF-8 de l’accent sont également encodés.

Le serveur décode ensuite ces représentations pour retrouver la valeur recherchée. Cette opération est réversible et ne protège pas un secret. Il faut distinguer encodage des caractères, emplacement du paramètre et chiffrement de la communication : ces mécanismes répondent à des besoins différents.

Choisir la méthode selon l’intention de l’action

Une recherche de chapitre convient à GET : la demande peut être répétée ou conservée comme favori pour retrouver la même représentation. Une soumission destinée à enregistrer une inscription correspond à un traitement qui peut modifier l’état du serveur et utilise habituellement POST.

Le serveur doit néanmoins programmer ce sens correctement. Changer seulement l’attribut du formulaire ne crée ni validation ni enregistrement dans une base. Pour analyser un exercice, identifiez le but de la requête, les paramètres présents, leur emplacement et la réponse attendue. Une méthode indique une convention d’échange, pas l’intégralité du fonctionnement de l’application.

De la compréhension à l’autonomie

À vous de résoudre

Cherchez d’abord par vous-même. Vérifiez les résultats demandés, utilisez les indices si nécessaire, puis comparez votre méthode à la correction.

Les erreurs qui méritent un détour

Confondre le label avec le nom du paramètre

Le label renseigne l’utilisateur ; name détermine la clé envoyée par le formulaire.

Présenter POST comme une protection cryptographique

GET et POST organisent la demande ; HTTPS protège le transport dans les deux cas.

Le prochain pas

• L’architecture de von Neumann

Retrouver le catalogue de Première

Ce chapitre s’appuie sur le programme officiel de Première (PDF, nouvel onglet). Les explications et exercices sont proposés pour l’apprentissage.