send() et HTTP

Le
n
Bonjour à tous, je fais un serveur de synchronisation SyncML pour
synchroniser des téléphones mobiles.

lorsque le mobile demande une synchronisation au serveur, le serveur
fait un accept() sur la socket qui correspond, lit la demande du
mobile et génère une réponse (jusque là, ça fonctionne impécabl=
e)
Le problème c'est pour envoyer la réponse, là je fait la chose
suivante :

length = len(response)
head = []
head.append("HTTP/1.1 200 OK")
head.append("Server: myPythonServer")
head.append("Cache-Control: no-store, no-cache, must-revalidate, post-
check=0, pre-check=0")
head.append("Pragma: no-cache")
head.append("Content-Length: "+str(length)+"")
head.append("Content-Type: application/vnd.syncml+wbxml")
head = ''.join(head)
client.send(head+response)

(je me suis inspiré des trames sniffées entre le téléphone et un si=
te
de synchronisation).

Sauf que ça ne doit pas être la bonne méthode car quand je sniffe les
trames, ma trame (qui contient les flags PSH et ACK) est suivie d'une
trame provenant du téléphone et contenant les flags FIN et ACK et
aucune donnée. La connection s'arrête alors à ce point.

et quand je compare mes données avec celle sinffées entre le mobile et
le site de synchronisation, le contenu de la réponse est identique, je
pense donc que le problème vient de la méthode d'envoi.

Pouvez vous m'aider, j'ai un peut de mal à résoudre moi même

Fabien
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bruno Desthuilliers
Le #640368
Bonjour à tous, je fais un serveur de synchronisation SyncML pour
synchroniser des téléphones mobiles.

lorsque le mobile demande une synchronisation au serveur, le serveur
fait un accept() sur la socket qui correspond, lit la demande du
mobile et génère une réponse (jusque là, ça fonctionne impécable)
Le problème c'est pour envoyer la réponse, là je fait la chose
suivante :

length = len(response)
head = []
head.append("HTTP/1.1 200 OKn")
head.append("Server: myPythonServern")
head.append("Cache-Control: no-store, no-cache, must-revalidate, post-
check=0, pre-check=0n")
head.append("Pragma: no-cachen")
head.append("Content-Length: "+str(length)+"n")
head.append("Content-Type: application/vnd.syncml+wbxmlnn")
head = ''.join(head)
client.send(head+response)


Ca ne répond pas forcément à ta question, mais:

head = "rn".join((
"HTTP/1.1 200 OK",
"Server: myPythonServer",
"Cache-Control: no-store, no-cache, must-revalidate," +
"post-check=0, pre-check=0",
"Pragma: no-cache",
"Content-Length: %s" % len(response),
"Content-Type: application/vnd.syncml+wbxml",
))

Bruno Desthuilliers
Le #640366
Le n change de valeur selon la plateforme (012 sur Unix, 015 sur Mac
et 015 suivi de 012 sur Windows). Il se trouve que sur Unix, ça
marche. Mais ce n'est pas propre.



merci pour tes conseil, je remplace donc les rn par des 1512.
J'y gagne un peut en portabilité comme ça.
Pour gérer ça proprement, j'ai pas trouvé sur le coup, mais bon
maitenant que ça marche, ça m'a permis de mieux comprendre le
fonctionnement de tous ça :)

En tout cas, merci à tous, j'ai réussi ce soir ma première synchro
avec le téléphonne mobile, preuve que mon serveur de synchronisation
fonctionne !


Bingo ! Tu paie le champagne ?-)


Amaury Forgeot d'Arc
Le #640107
Bonjour,

Bonjour à tous, je fais un serveur de synchronisation SyncML pour
synchroniser des téléphones mobiles.

lorsque le mobile demande une synchronisation au serveur, le serveur
fait un accept() sur la socket qui correspond, lit la demande du
mobile et génère une réponse (jusque là, ça fonctionne impécable)
Le problème c'est pour envoyer la réponse, là je fait la chose
suivante :

length = len(response)
head = []
head.append("HTTP/1.1 200 OKn")
head.append("Server: myPythonServern")
head.append("Cache-Control: no-store, no-cache, must-revalidate, post-
check=0, pre-check=0n")
head.append("Pragma: no-cachen")
head.append("Content-Length: "+str(length)+"n")
head.append("Content-Type: application/vnd.syncml+wbxmlnn")
head = ''.join(head)
client.send(head+response)

(je me suis inspiré des trames sniffées entre le téléphone et un site
de synchronisation).

Sauf que ça ne doit pas être la bonne méthode car quand je sniffe les
trames, ma trame (qui contient les flags PSH et ACK) est suivie d'une
trame provenant du téléphone et contenant les flags FIN et ACK et
aucune donnée. La connection s'arrête alors à ce point.

et quand je compare mes données avec celle sinffées entre le mobile et
le site de synchronisation, le contenu de la réponse est identique, je
pense donc que le problème vient de la méthode d'envoi.

Pouvez vous m'aider, j'ai un peut de mal à résoudre moi même...


Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer les n
par des rn

Au cas où...

--
Amaury

n
Le #640105
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer le s n
par des rn


J'ai oublié de précisé, je suis sous linux.
Je ne suis pas certain, mais je crois que c'est seulement sous windows
qu'il faut utiliser rn sous linux, le n fait les deux (à
confirmer).

Fabien

n
Le #640104
On 22 juil, 08:57, Bruno Desthuilliers



Bonjour à tous, je fais un serveur de synchronisation SyncML pour
synchroniser des téléphones mobiles.

lorsque le mobile demande une synchronisation au serveur, le serveur
fait un accept() sur la socket qui correspond, lit la demande du
mobile et génère une réponse (jusque là, ça fonctionne impé cable)
Le problème c'est pour envoyer la réponse, là je fait la chose
suivante :

length = len(response)
head = []
head.append("HTTP/1.1 200 OKn")
head.append("Server: myPythonServern")
head.append("Cache-Control: no-store, no-cache, must-revalidate, post-
check=0, pre-check=0n")
head.append("Pragma: no-cachen")
head.append("Content-Length: "+str(length)+"n")
head.append("Content-Type: application/vnd.syncml+wbxmlnn")
head = ''.join(head)
client.send(head+response)


Ca ne répond pas forcément à ta question, mais:

head = "rn".join((
"HTTP/1.1 200 OK",
"Server: myPythonServer",
"Cache-Control: no-store, no-cache, must-revalidate," +
"post-check=0, pre-check=0",
"Pragma: no-cache",
"Content-Length: %s" % len(response),
"Content-Type: application/vnd.syncml+wbxml",
))



Je viens de tester avec ce que tu as écris, et ça fonctionne mieux, le
mobile ne me répond plus par un FIN et ACK, seulement le ACK (du coup
la connexion n'est pas fermée) le problème c'est qu'il devrais me
renvoyer sa réponse et qu'il ne le fait pas. Je ne sais pas pourquoi.
Donc apparement, il faut vraiment des 'rn' et non pas seulement des
'n'.

Bon ba merci bien en tout cas, il ne me reste plus qu'a comprendre
pourquoi ce mobile ne veut pas me répondre alors qu'il veut bien
répondre au site de synchronisation :(

Fabien


Amaury Forgeot d'Arc
Le #640103
On 22 juil, 08:57, Bruno Desthuilliers



Bonjour à tous, je fais un serveur de synchronisation SyncML pour
synchroniser des téléphones mobiles.
lorsque le mobile demande une synchronisation au serveur, le serveur
fait un accept() sur la socket qui correspond, lit la demande du
mobile et génère une réponse (jusque là, ça fonctionne impécable)
Le problème c'est pour envoyer la réponse, là je fait la chose
suivante :
length = len(response)
head = []
head.append("HTTP/1.1 200 OKn")
head.append("Server: myPythonServern")
head.append("Cache-Control: no-store, no-cache, must-revalidate, post-
check=0, pre-check=0n")
head.append("Pragma: no-cachen")
head.append("Content-Length: "+str(length)+"n")
head.append("Content-Type: application/vnd.syncml+wbxmlnn")
head = ''.join(head)
client.send(head+response)
Ca ne répond pas forcément à ta question, mais:


head = "rn".join((
"HTTP/1.1 200 OK",
"Server: myPythonServer",
"Cache-Control: no-store, no-cache, must-revalidate," +
"post-check=0, pre-check=0",
"Pragma: no-cache",
"Content-Length: %s" % len(response),
"Content-Type: application/vnd.syncml+wbxml",
))



Je viens de tester avec ce que tu as écris, et ça fonctionne mieux, le
mobile ne me répond plus par un FIN et ACK, seulement le ACK (du coup
la connexion n'est pas fermée) le problème c'est qu'il devrais me
renvoyer sa réponse et qu'il ne le fait pas. Je ne sais pas pourquoi.
Donc apparement, il faut vraiment des 'rn' et non pas seulement des
'n'.


Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF.
Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...

Bon ba merci bien en tout cas, il ne me reste plus qu'a comprendre
pourquoi ce mobile ne veut pas me répondre alors qu'il veut bien
répondre au site de synchronisation :(

Fabien





Bruno Desthuilliers
Le #639855
Apès avoir jeté un oeil dans httplib.py, je suggère de remplacer les n
par des rn


J'ai oublié de précisé, je suis sous linux.
Je ne suis pas certain, mais je crois que c'est seulement sous windows
qu'il faut utiliser rn sous linux, le n fait les deux (à
confirmer).


Effectivement, Windows et Unix n'utilisent pas la même convention pour
les fins de lignes. Mais c'est indépendant de ton problème, puisque le
marquage de fin de ligne à utiliser ici est celui déterminé par le
protocole HTTP.


Bruno Desthuilliers
Le #639854
(snip)
Donc apparement, il faut vraiment des 'rn' et non pas seulement des
'n'.


Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF.
Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...


Lol !-)

Mais PAQJS, non.


n
Le #637562
head = "rn".join((
"HTTP/1.1 200 OK",
"Server: myPythonServer",
"Cache-Control: no-store, no-cache, must-revalidate," +
"post-check=0, pre-check=0",
"Pragma: no-cache",
"Content-Length: %s" % len(response),
"Content-Type: application/vnd.syncml+wbxml",
))


ok, et entre le head et la réponse, n'est il pas nécéssaire d'insér er
des 'rn' ?
Est ce que je dois envoyer en deux paquet différents : dabort le head
et ensuite la réponse (avec deux send donc) ou est ce que je dois tout
concaténer dans un même paquet ? (et dans ce cas, comment dois-je
séparer les données du head ?)

Merci à tous pour votre aide.

Fabien

Paul Gaborit
Le #637561
À (at) Thu, 26 Jul 2007 00:35:45 +0200,
Amaury Forgeot d'Arc
Apparemment, ftp et smtp fonctionnent aussi à coups de CRLF.
Ce sont sans doute des Windowsiens qui ont inventé ces protocoles...


Pas du tout.

Mais quand il a fallut choisir une fin de ligne "réseau", ceux qui
l'on fait se sont dit (avec raison) qu'en mettant les deux caractères,
la fin de ligne serait reconnu par tout le monde (avec parfois un
caractère parasite avant ou après mais c'est moins grave que de ne pas
voir de fin de ligne du tout).

--
Paul Gaborit -
Publicité
Poster une réponse
Anonyme