[WD7/WD8] Bug : SoapExecute() ne respecte pas les RFC
1 réponse
MiF
Bonjour,
Après de nombreuses heures perdues à essayer de faire fonctionner un serveur
Soap sur un site dont le réseau est protégé par un firewall/analyseur de
protocole (qui vérifie que les protocoles qui passent par les divers ports
respectent les RFCs respectives, par exemple que le port 80 est bien utilisé
pour faire du HTTP), je m'aperçois que les requêtes HTTP construites par
Windev pour encapsuler SOAP ne respectent pas les RFC. Elles dont donc
bloquées par le firewall en question.
Je poste donc ce message pour éviter à d'autres la même perte de temps.
Pour les curieux, j'ajoute ci-dessous le dump de la requête en question,
telle que produite par Windev. D'après l'analyseur de protocole, la
violation de la RFC se situe au dernier octet de la requête, car le dernier
caractère 0A ne doit pas être ajouté seul (il doit soit être enlevé, soit
précédé d'un 0D).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
MiF
Bonjour,
Je corrige mes propos.
La violation des RFC ne se situe pas au niveau du contenu des derniers octets, mais de leur comptabilisation.
C'est la taille de la requête indiquée dans le Content-Length96 qui est erronée. Les 4 derniers octets 0d.0a.0d.0a n'ont pas été comptabilisés. La valeur du Content-Length devrait donc être de 1100.
L'analyseur de protocole considère donc qu'il s'agit d'une seconde requête incomplète, et il rejette donc la trame.
Michel Fages
"MiF" a écrit dans le message de news:X%J0c.54127$
Bonjour,
Après de nombreuses heures perdues à essayer de faire fonctionner un
serveur
Soap sur un site dont le réseau est protégé par un firewall/analyseur de protocole (qui vérifie que les protocoles qui passent par les divers ports respectent les RFCs respectives, par exemple que le port 80 est bien
utilisé
pour faire du HTTP), je m'aperçois que les requêtes HTTP construites par Windev pour encapsuler SOAP ne respectent pas les RFC. Elles dont donc bloquées par le firewall en question.
Je poste donc ce message pour éviter à d'autres la même perte de temps.
Pour les curieux, j'ajoute ci-dessous le dump de la requête en question, telle que produite par Windev. D'après l'analyseur de protocole, la violation de la RFC se situe au dernier octet de la requête, car le
dernier
caractère 0A ne doit pas être ajouté seul (il doit soit être enlevé, soit précédé d'un 0D).
La violation des RFC ne se situe pas au niveau du contenu des derniers
octets, mais de leur comptabilisation.
C'est la taille de la requête indiquée dans le Content-Length96 qui est
erronée. Les 4 derniers octets 0d.0a.0d.0a n'ont pas été comptabilisés. La
valeur du Content-Length devrait donc être de 1100.
L'analyseur de protocole considère donc qu'il s'agit d'une seconde requête
incomplète, et il rejette donc la trame.
Michel Fages
"MiF" <mif@mif.com> a écrit dans le message de
news:X%J0c.54127$kb7.388095173@news.nnrp.ca...
Bonjour,
Après de nombreuses heures perdues à essayer de faire fonctionner un
serveur
Soap sur un site dont le réseau est protégé par un firewall/analyseur de
protocole (qui vérifie que les protocoles qui passent par les divers ports
respectent les RFCs respectives, par exemple que le port 80 est bien
utilisé
pour faire du HTTP), je m'aperçois que les requêtes HTTP construites par
Windev pour encapsuler SOAP ne respectent pas les RFC. Elles dont donc
bloquées par le firewall en question.
Je poste donc ce message pour éviter à d'autres la même perte de temps.
Pour les curieux, j'ajoute ci-dessous le dump de la requête en question,
telle que produite par Windev. D'après l'analyseur de protocole, la
violation de la RFC se situe au dernier octet de la requête, car le
dernier
caractère 0A ne doit pas être ajouté seul (il doit soit être enlevé, soit
précédé d'un 0D).
La violation des RFC ne se situe pas au niveau du contenu des derniers octets, mais de leur comptabilisation.
C'est la taille de la requête indiquée dans le Content-Length96 qui est erronée. Les 4 derniers octets 0d.0a.0d.0a n'ont pas été comptabilisés. La valeur du Content-Length devrait donc être de 1100.
L'analyseur de protocole considère donc qu'il s'agit d'une seconde requête incomplète, et il rejette donc la trame.
Michel Fages
"MiF" a écrit dans le message de news:X%J0c.54127$
Bonjour,
Après de nombreuses heures perdues à essayer de faire fonctionner un
serveur
Soap sur un site dont le réseau est protégé par un firewall/analyseur de protocole (qui vérifie que les protocoles qui passent par les divers ports respectent les RFCs respectives, par exemple que le port 80 est bien
utilisé
pour faire du HTTP), je m'aperçois que les requêtes HTTP construites par Windev pour encapsuler SOAP ne respectent pas les RFC. Elles dont donc bloquées par le firewall en question.
Je poste donc ce message pour éviter à d'autres la même perte de temps.
Pour les curieux, j'ajoute ci-dessous le dump de la requête en question, telle que produite par Windev. D'après l'analyseur de protocole, la violation de la RFC se situe au dernier octet de la requête, car le
dernier
caractère 0A ne doit pas être ajouté seul (il doit soit être enlevé, soit précédé d'un 0D).