Discussion :

[akrodev]

Bonjour,

J'aimerai utiliser Exchange activesync à travers un proxy https qui filtre les user-agent. Le problème c'est que Windows mobile 6 ne permet pas de régler un proxy https, seulement http.

Je me suis dit que j'allais coder un petit relai pour réaliser l'opération. Voilà comment je l'ai construit:
1. Activesync est configuré pour se connecter sur le serveur locahost.
2. TcpListener écoute sur le port 443.
3. Activesync se connecte -> on récupère le flux streamIN
4. Connexion TcpClient au proxy https -> on récupère le flux streamOUT
5. Envoi de la requête "CONNECT serveur:443 HTTP/1.1 + UserAgent" sur streamOUT
6. Réponse du proxy https "HTTP 200". Donc c'est bon.
7. Après je fait une simple recopie byte par byte d'un flux à l'autre en uplink et en downlink.

J'ai 2 questions:
- Si j'essaie de convertir en ASCII les byte que je transfère c'est illisible. Quand on appelle Read sur un NetworkStream créé à partir de TcpClient on lit le payload TCP ? ou toute la trame TCP ?
- Activesync n'arrive pas à se synchroniser avec ce relai. Voyez-vous une erreur de conception ?

Merci pour vos réponses

[akrodev]

Bonsoir,

J'ai avancé sur mon problème. Je peux répondre à ma première question.

Effectivement appeller Read() sur un NetworkStream créé à partir de TcpClient permet de lire le payload des trames TCP. Très pratique on ne garde que les trames SSL par exemple sans se soucier de tout ce qui est propre au TCP.
Il est bien evidemment ridicule de vouloir convertir les octets transmis en chaîne de caractères puisque le protocole SSL ne se lit pas comme du texte. Il faut savoir à quels champs correspondent les octets et on comprend les échanges.

En me plongeant dans la spécification des trames SSL et en capturant les byte un par un au niveau de mon proxy, j'ai pu retracer les échanges entre activesync et le serveur exchange.

Le négociation SSL se fait bien entre les deux parties jsqu'au bout. Ensuite devrait commencer les échanges cryptés mais à ce moment là curieusement je reçois l'octet -1 de la part d'Activesync.

D'après le descriptif de la fonction Readbyte() cela veut dire:

Valeur de retour
Cast de l'octet non signé en Int32 ou -1 s'il se situe à la fin du flux

Que signifie la fin du flux pour une socket ?
Cela veut dire qu'elle a été fermée ? Si c'est le cas comment garder cette connection vivante pour le reste des échanges ?


Merci pour votre aide.

[Bluedeep]

Que signifie la fin du flux pour une socket ?

Cela veut dire qu'elle a été fermée ? Si c'est le cas comment garder cette connection vivante pour le reste des échanges ?

Non, ça signifie que tu as lu l'ensemble des octets envoyés, pas que la socket est fermée.

[akrodev]

L'appel à ReadByte() n'est pas bloquant alors ?
Et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

stream.DataAvailable == false

et équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

stream.ReadByte() == -1

[Bluedeep]

Non, il te retourne un Byte si il y en a un sur le flux, ou -1 dans le cas contraire.

Ceci dit c'est une méthode de lecture particuliérement inefficiente. (comme mentionné, elle est implémentée en appelent Read sur un tableau de 1 octets).

[akrodev]

Je comprends mieux pourquoi mon programme s'arrête alors.
Merci pour ton aide.

Dernière question: existe-t-il une méthode bloquante de lecture de stream ?