Posté par Obsidian .
En réponse au message POST.
Évalué à 5.
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 ?
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 :
# CGIs et serveurs Web, même combat.
Posté par Obsidian . En réponse au message POST. É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.