PureBasic

Le dialogue client/serveur en http est très simple et largement documenté. Ton navigateur (le client) ne fait le plus souvent que demander un fichier, qui lui est gentiment envoyé par le serveur. Mais dans l'entête de la demande (on appelle ça une requête), il petit y avoir quelques infos, par exemple le nom du navigateur, la date, et éventuellement le contenu du cookie qui aura été précédemment créé sur le client à la demande du serveur. La requête peut aussi contenir des paramètres, soit encodés dans l'URL (tout ce qui suit le ?), ou dans l'entête, de façon cachée. C'est le cas quand on remplit un formulaire, mais aussi avec du javascript et/ou avec l'ajax.

Merci Djes de tes explications.
C'est vrai que les pages web deviennent de plus en plus complexes, perfectionnée.
Du coups je m'étais mis en tête que les transferts de données clients/serveur se compliquaient en même temps...

Il faudra que je trouve des pages compliquée pour voir le comportement.
Ce qui m'inquiète, c'est gérer le flash ou autre connerie moderne qui rendent le code illisible.
Des fois en une ligne, y a tout un tableau de centaines de liens et données
On peut même pas copier coller les données, car c'est que graphique

Falsam a écrit :Le lien qui a servi à faire ça, fait appel à un script php qui sera interprété par le serveur sans que le navigateur (j'ai bien dit le navigateur hein ?) sache quoique ce soit hormis une réponse html par exemple pour te dire que la modification est bien pris en compte.

Bon...j'ai essayé de comprendre...
Et loupé...

Moi ce qui m'échappe, c'est comment le serveur avec un script PHP, il peut à distance récupérer ce qu'on a écrit dans un champs
Moi je croyais que quand on remplissait un formulaire, qu'on le soumettait, la page envoyait chaque champs et sa valeur dans l'adresse si c'est en GET et en invisible si c'est en POST

C'est rare que ce soit en GET...alors comment on pourrait faire pour recuperer ce qu'envoi le navigateur en methode POST, car je crois que c'est ça en fin de compte qui me manque

Que ce soit en post ou en get, le script php reçoit les données qui lui sont transmises par apache, ça ne change rien.

Alors la....c'est magique

À condition que tu ne t'adresses pas à un site en HTTPS, tu peux voir facilement le dialogue entre ta machine et un serveur web (local ou distant) en installant un simple proxy (ex: privoxy) et en paramétrant les logs de ce dernier sur le mode détaillé. (Pour privoxy, si tu veux qu'il "cause" il faut l'installer dans un répertoire où il peut écrire, donc pas dans 'program files' sur un windows "moderne")

Tout le contenu de ta requête POST apparait à la fin de la ligne
Received: from socket xxx: POST ...
(c'est bien Receive car le proxy reçoit, puis renvoi au serveur)

Bon, il faut aussi que ton application sache utiliser le proxy, ce qui est le cas si le composant s'appuie sur IE

Bonjour Marc56

Coooool !!! Encore une combine que je connaissais pas
Je vais essayer ce que tu me conseille, merci
Bon faut dire que bien que le Web m'épate de par ses performances. ..j'y comprend pas grand chose

Hier, j'ai essayé plein de trucs tout azimuts, mais rien de simple...enfin pour moi
J'ai même essayé de faire marcher un pseudo OLE pour chrome sans succès

Faut dire que j'aime pas trop firefox, je sais pas pourquoi. .
Sur le web Y'a noir de trucs soit disant geniaux pour piloter des navigateurs, mais faut reconnaître que pour une fois BILOU a fait un truc simple et qui marche sur IE avec l'automation. ..

Et maintenant, j'ai un autre problème, je suis un XPien converti, même si y a plus de maj
Et hier j'ai découvert que mes pages de formulaires étaient différentes sur IE de celles de chrome
Normal les sites même pour faire un simple formulaire, font appel à des technologies récentes.
Alors j'ai essayé d'installer IE8, et BILOU veut pas....faut W7, j'en ai marre qu'on me force la main..
Du coups les webgadget marche plus, puisque FRED ne donne plus la possibilité d'utiliser un autre moteur comme il le faisait avant avec FIREFOX

J'suis dans une belle OUMPHA
C'est pourquoi, j'aimerais tant m'affranchir de tout ce bordel qui change constamment, discuter direct en bugne à bugne, avec les serveurs, sans passer par tout ce fatra de navigateur, plugin, protocole de pilotage
Juste PB et lui, entre hommes

Mais J'suis devant mon IDE jaune vide...et J'sais pas quoi lui dire

Je suis tombé sur des supers codes de darkdragon ou autres copains qui font des requêtes HTTP.
Super ça marche, j'obtiens le source de la page
Mais après, j'en fais quoi ???
Si c'est un formulaire, comment je le rempli et envoi au "maître d'hôtel"?

C'est pourquoi je m'étais dit naïvement, que si "j'esgourdais" ce que renvois mon propre chrome, j'analyserais l'envoi, et pourrais peut être parser cette réponse afin de faire la prochaine moi même, comme un grand avec PB

Mais voilà rien de simple pour lire ce qui sort de mon propre navigateur. .
Il veut rien me dire. ..Même quand je lui explique que je suis son papa, et que sans moi il n'existerait pas..
Aaaaaaaa !!! Ces gosses. ..Même pas la reconnaissance du ventre

Si je relis ton premier post, ton souhait est uniquement de savoir ce que « dit » le webgadget au serveur web lorsqu'il appelle une page (fusse-t-elle avec un formulaire) ? (en fait simplement ce qu'on appelle le 'dialogue http')

Oui ça n'a pas changé.
Je voudrais savoir ce qu'ils se racontent.
Ce qui arrive du serveur c'est facile chaque navigateur a une option lecture du source.
Mais ce qui part du navigateur. ...c'est plus ou moins secret.
Et même avec un webgadget et sa callback, on ne peut lire que l'URL qu'il envoi,

Avec un sniffer ou peut tout lire, mais là pour le coup, pas facile de retrouver le texte exact à envoyer à la place du nnavigateur, dans le cas ou j'essaierai de m'en passer

J'ai fait une recherche dans Google sur requête http post, voici ce que j'ai trouvé du premier coup http://openclassrooms.com/courses/les-requetes-http

Merci Djes
J'ai tout lu..
Au prime abord ça paraît enfantin...
C'est quand tu te retrouve devant la reponse d'un serveur te soumettant un formulaire que l'évidence en prend un coup dans les chaillottes.
Faut que je fasse des essais, en reperant les id des champs, et encore des fois Y'a pas d'id, c'est des classes (pourquoi faire simple. ..)
Puis envoyer ça en requette dans une ligne.
Je pense que le choix de l'envoi POST ou GET n'est pas imposé par le serveur ??

En clair tu veux repérer les champs d'une page quelconque, créer une requête post, et renvoyer au serveur. Si c'était ton site, ce serait simple, mais j'ai l'impression que c'est un site très différent. Du coup, je ne suis pas sûr que tout soit fait pour faciliter ta recherche

Le gros problème, c'est de gérer les cookies; c'est pour cela que je préfère faire de l'automation.

@DJES
Tout à fait, c'est en fait pour faire des automatisation de taches répétitives.
Certaines mauvaises langues comme quelqu'un que je ne citerais pas, que son pseudo commence par FAL, et fini par SAM appelerait un BOT
Mais encore une fois, même si le code fait parti des "Cpasbien", moi c'est pour mon boulot, mais aussi pour moi, car j'ai très souvent besoin d'automatiser des dépôts d'annonces de vente, les relancer, etc ...
Et comme on a pas encore créé le forum DARKPB, bah je suis obligé de demander sur la place publique

Tu as raison, ce genre de site ne fait pas grand chose pour aider, car ils ne veulent pas trop être submergés de pelo qui posent des annonces par centaines
C'est pourquoi, depuis des années, je fait ça en automation et IE, mais pour toutes les raisons de MAJ, de portabilité, etc, j'en ai un peu marre de IE, même si je doit reconnaître que l'OLE, même si c'est pas parfait, c'est quand même le pied.

@NICO
Bonjour Nico
Je ne savais pas que y'avait un probleme de plus pour les cookies
Tu as raison, car des fois dans le navigateur quand tu les bloques, il te previent que ça va pas plaire, mais alors pas plaire du tout au site
Bon je sent que c'est pas demain la veille que je vais arrêter l'automation

Y sont pas professionnels ces "serveurs", car je croyait que dans le monde de la restauration, le client etait roi