2010-08-10 3 views
0

J'ai une application Client-Serveur de propriétaire écrite en MFC. Aucun client autre que mon client ne va communiquer avec le serveur. Pour des raisons sûres, nous utilisons HTTP. Jusqu'à notre connaissance, nous avons utilisé content-length pour décrire le client où le corps de la réponse se termine. Maintenant, nous avons une situation où la longueur n'est pas connue à l'avance et nous ne pouvons pas mettre les données en tampon. J'ai lu dans le Rfc qu'il y a le codage de transfert en morceaux. Le problème est que je ne veux pas implémenter le formatage qui est défini dans le rfc (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6 section 3.6.1). Le problème est que si j'utilise ma propre mise en forme de bloc et que la classe MFC essaie ensuite de l'analyser, il y aura une erreur car ce n'est pas le format attendu, tel que défini dans la RFC.Codage de transfert en bloc HTTP et MFC

Est-il possible de mettre "Chunked Transfer Coding" dans les en-têtes de réponse, puis d'utiliser mon propre formatage de segments? Ou, en d'autres termes, est-ce que les classes MFC, lorsqu'elles voient "Chunked Transfer Coding" dans les en-têtes de réponse, essaient d'analyser le corps en fonction de la définition du formatage chancelé dans le rfc?

Répondre

0

Je ne suis pas sûr de comprendre.

1) Quel est le problème avec le codage en segments tel que défini par RFC 2616? 2) Et comment le code existant est-il censé traiter un encodage qu'il ne connaît pas?

+0

Objectivement, rien ne va pas avec cela. Pour une raison qui ne correspond pas à présent. L'idée est que je vais définir mon propre encodage et l'implémenter dans le client et le serveur. – user88637

+0

Eh bien, le framework HTTP doit comprendre l'encodage pour voir où le message se termine. Il faudrait donc l'implanter à un niveau plutôt bas. –