Bonjour à tous :)
J'ai implémenté un plugin http pour mon petit serveur, qui gère actuellement GET et HEADER, mais j'aimerais bien ajouter POST afin d'être compatible http 1.0...
Mon problème, c'est que je lis correctement la requête et le body, mais que je ne sais pas quoi faire de ce dernier ^_^'
J'ai examiné la RFC, qui indique différents code de retour suivant que l'on a créé une ressource ou pas. Mais ce que je ne comprend pas, c'est la manière dont on fournit les données de POST aux documents.
Par exemple, pour un CGI c'est pas compliqué, on balances tout sur son stdin en modifiant quelques variables d'environnement, et on renvoie au client le stdout, mais pour une banale page web, comment ça se gère ?
J'ai l'impression que gérer POST revient à gérer obligatoirement un backend (CGI, ou autre appli) à laquelle on fournit les données, mais j'aimerais avoir confirmation...
D'autre part, dois-je empêcher l'envoi d'un fichier binaire avec POST ? Normalement il y a PUT en http 1.1, mais peut être que c'est autorisé malgré tout ?
Merci d'avance pour vos réponses :)
Forum Programmation.web POST
22
juin
2005
# post
Posté par or zax . Évalué à 3.
Donc c'est comme get, mais au lieu d'être au niveau de l'adresse, c'est après, dans les entêtes de la requêtes HTTP.
# CGIs et serveurs Web, même combat.
Posté par Obsidian . Évalué à 5.
Ben pour une banale page web, en principe c'est ton serveur qui gère tout cela. Ce que je tire de ton message, c'est qu'apparement, ton plugin, c'est un mini serveur web. Donc dans ce cas (POST), tu dois refaire le travail exactement comme tu le ferais avec une application CGI, qui n'est que la définition de l'interface entre le serveur WEB et ton application, ce qui n'a pas lieu d'être ici puisque tu écoutes directement les connexions.
Dans le cas de POST, les données pouvant être très longues et/ou confidentielles, il est hors de question de les coder dans l'URL ni même dans les entêtes ! Elles font partie du document. Ce document est ensuite présenté à la discrétion du client (le navigateur), mais en général c'est :
Content-Type: application/x-www-form-urlencoded
... qui est un type mime défini et donc (probablement) décrit clairement par une RFC. La mauvaise nouvelle, c'est que si tu ne peux pas utiliser un module tout fait (style CGI en perl), il faudra te recoltiner l'implémentation des différents protocoles si tu veux être parfaitement compatible avec tes clients, à moins d'utiliser une entête du style "Accept-xxxx" pour informer le client des langues que tu connais vraiment.
En pratique, les arguments passés par un formulaire POST au moment où tu cliques sur un bouton sont encodés exactement de la même façon qu'un GET mais sur la première ligne des données, après les entêtes.
Fais par exemple un "nc -l -p 5678" pour te mettre à l'écoute du port 5678 (par exemple), puis écris une petite page web qui contiendra juste un formulaire de type POST et dont l'action sera "http://127.0.0.1:5678(...)". Tu obtiendras un exemple parlant de ce qu'un navigateur web envoie à un serveur dans ta situation.
Pour tes codes de retour, c'est le protocole HTTP qu'il faut respecter. Cela n'a rien à voir avec le POST en particulier, si ce n'est que c'est la plupart du temps avec un formulaire que l'on fait des opérations coté serveur autre que la simple consultation de page. Donc tu écris simplement sur la sortie standard :
HTTP/1.0 200 OK
Content-Type: text/html
Début de ton document ...
et tout devrait marcher comme sur des roulettes.
[^] # Re: CGIs et serveurs Web, même combat.
Posté par JaguarWan . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.