Pour clarifier les choses, il faudrait revenir un peu au mode de
fonctionnement d'internet.
Les modes dont on parle (http get, http post et ftp) sont des
protocoles régis par des "RFC" qui font loi sur internet parce que
tout le monde y adhère. Ces RFC (Request For Comment) passent par des
étapes de validation dans un petit monde très particulier qu'on
appelle IETF (Internet Engineering Task Force) qui est une sorte
d'association informelle où il faut montrer sa compétence pour être
co-opté. IETF est pris en charge par l'ISOC (Internet Society) qui
est l'organe "officiel" d'internet (dans la mesure ù il y a quelque
chose d'officiel).
Ces trois modes sont donc des normes de fait qui permettent à deux
programmes tournant sur des machines différentes de dialoguer et de
se comprendre. Cela veur dire que ces méthodes on un BUT, et que la
façon d'opérer permet de répondre A CE BUT. Si vous essayez de faire
autre chose que ce que le but de la RFC, vous pouvez avoir des
déconvenues ou vous heurter à des difficultés (qu'un nouvel RFC peut
permettre de résoudre s'il est suivi)
Pour ce qui concerne le serveur, on n'a pas trop le choix de quel est
le programme http et le programme ftp : il s'agit d'un programme qui
est soit http (par exemple Apache ou IIS) soit un programme FTP (et
normalement, il n'y en a qu'un seul de chaque type)
-> pour le http, on formate un header (c'est RB qui le fait en créant
un http socket) pour que le serveur soit capable de reconnaitre que
le message arrivant est destiné au programme en charge de http (dans
le cas de apache sous Linux, ce sera par exemple le deamon httpd). La
partie principale est une url qui permet d'identifier la "page" (le
fichier) que apache doit charger en réponse à la demande et renvoyer
sous forme http au demandeur (le programme rb). Si cette page est une
partie exécutable, elle est exécutée par apache par l'appel de
processus (c'est d'ailleurs pour cela qu'il faut compiler php avec
apache dans le serveur).
Ce programme appelé (par exemple php puisque tout le monde parle de
php mais perl pour tous ceux qui font de l'unix et le plus présent
pour les parties "système" du serveur) peut recevoir des paramètres
de deux manières différentes.
.. Une première méthode consiste à lui envoyer dans le buffer de STDIN
à charge au programme de réception de décortiquer le buffer (fait
automatiquement par php, mais à faire explicitement en perl par une
routine)
.. Une deuxième méthode consiste à le passer dans la variable $ENV (ou
%ENV en perl).
On appelle la première méthode POST et la deuxième méthode GET, mais
en fait, dans tous les programmes perl (côté serveur), je décortique
les deux pour les mettre dans un tableau.
Pour l'utilisateur, la seule différence notable est - comme l'a fait
remarquer un des colistiers - que l'adresse complète apparait dans la
méthode GET car le $ENV est envoyé dans l'URL et que donc les
navigateurs l'affichent en standard (ce qu'on peu éviter en faisant
un rewrite de l'url, mais bon ...).
NOTE IMPORTANTE : quand on passe des paramètres en http (en POST ou
en GET, on a vu que l'effet est le même pour ce qui est du passage de
paramètres), on les retrouve dans un programme qui a la main et peut
donc agir selon la programmation qu'on fait par exemple, mettre à
jour une base de données ou renvoyer une page modifiée à la demande
http. Donc, peut importe sle GET ou le POST, on retrouvera la même
chose, c'est l'endroit de passage qui change. Par contre, il est TRES
important de bien retenir qu'on se retrouve dans un programme
utilisateur actif sur le serveur et qu'on peut faire ce qu'il faut
faire car on a la main.
-> FTP
Le SFTP est un protocole de dialogue plus simple qui définit le
header FTP pour que le serveur reconnaisse une demande FTP et la
transmette au programme FTP du serveur. (Sur la plupart des Unix, on
a tendance aujourd'hui à utiliser le daemon proftpd)
En gros, le FTP permet uniquement de récupérer un fichier et d'écrire
un fichier (bien sûr, on peut changer de repertoire, en créer un, en
effacer un, effacer des fichiers etc...).
La grosse différence avec http est que le programme FTP ne prévoit
pas de passer la main à un quelconque programme utilisateur pour lui
faire mettre une base de données à jour en temps réel etc.. C'est
essentiellement un process de traitement batch (par lots).
A partir de là, il ne devrait pas y avoir d'hésitation entre le choix
du http et du ftp ou des deux : le FTP ne PEUT PAS FAIRE DU TEMPS
REEL. Mais comme il est beaucoup plus simple, il devrait être préféré
dès qu'on peut l'utiliser, parce qu'il prend moins de ressources (y
compris et surtout au niveau des ressources serveur)
Si on a besoin de temps réel (par exemple boutique ou paiement en
ligne), il n'y a pas le choix, il faut prendre du http pour dialoguer
pour pouvoir passer la main un programme.
===================
Remarque complémentaire : le http n'est qu'un formatage par le
protocole et ne veut pas dire que vous allez afficher une page.
Ainsi par exemple, vous pouvez très bien simuler une demande à une
base de données sur le serveur sans que personne ne voie rien : il
suffit par exemple que vous fassiez un appel en http (get ou post, on
s'en fout) qui contient le paramètre query (chaîne de caractères) qui
soit un query SQL sur une base connue par le programme toto.php qu'on
appelle.
toto.php fait la demande à la base sur le serveur et l'écrit en
sortie ce qui fait qu'on retrouve la chaîne en réponse dans le
programme RB.
Dans ce dernier exemple, on s'est inventé un nouveau protocole à nous
entre un prog RB et le serveur (le query et le format de la réponse
en retour) qu'on a encapsulé dans du http sans jamais vraiment faire
du web !
===================
En espérant que ces remarques vous ouvrent des horizons et éclairent
un peu une discussion qui ne posait pas vraiment bien les choses
Michel Lo
BELT
45, rue Aristide Briand
92300 LEVALLOIS-PERRET
L'intégrité de ce message n'étant pas assurée sur internet, BELT ne
peut être tenue responsable de son contenu. Toute utilisation ou
diffusion non autorisée est interdite. Si vous n'êtes pas
destinataire de ce message, merci de le détruire et d'avertir
l'expéditeur.
The integrity of this message cannot be guaranteed on the Internet.
BELT can not therefore be considered responsible for the contents.
Any unauthorized use or dissemination is prohibited. If you are not the
intended recipient of this message, then please delete it and notify
the sender.
Le 13 juin 07 à 14:36, Pascal PLUCHON a écrit :
Sinon tu peux utiliser la méthode dont j'ai parlé l'autre jour :
poster dans un formulaire et dialoguer avec un .php qui récupère le
champ et enregistre le fichier... C'est ce que je fait pour envoyer
des images sur un serveur (en encodant en base64 parce que dans le cas
des images c'est du binaire)
Le 13/06/07, Antoine Crêtaux<antoine at cretaux dot fr> a écrit :
Ayant obtenu par un get le contenu de ma page je pensais par un post
pouvoir le modifier. A y bien réfléchir heureusement que cela n'est
pas possible cela voudrait dire que n'immporte qui pourrait le
faire...
Le 13 juin 07 à 12:39, Powel a écrit :
> Il n'y a pas le choix. Comme l'a détaillé Daniel Chiaralello, GET
> et POST servent à transmettre des informations (dont des fichiers)
> à une page web mais ne permettent aucunement de placer ces derniers
> directement sur le serveur. Le FTP est de loin la solution la plus
> adaptée.
>
> Powel
>
>
> Le 13 juin 07 à 12:30, Antoine Crêtaux a écrit :
>
>> je crois que je vais rester en FTP... Merci
>>
>
Michel Lo
BELT
45, rue Aristide Briand
92300 LEVALLOIS-PERRET
L'intégrité de ce message n'étant pas assurée sur internet, BELT ne
peut être tenue responsable de son contenu. Toute utilisation ou
diffusion non autorisée est interdite. Si vous n'êtes pas
destinataire de ce message, merci de le détruire et d'avertir
l'expéditeur.
The integrity of this message cannot be guaranteed on the Internet.
BELT can not therefore be considered responsible for the contents.
Any unauthorized use or dissemination is prohibited. If you are not the
intended recipient of this message, then please delete it and notify
the sender.
|