Téléchargement de contenu URLOpenPullStream et gzip - besoin de données non compressées

Question

J'utilise URLOpenPullStream avec des rappels IBindStatusCallback et IHttpNegotiate pour gérer les messages de négociation, d'état et de données. Le problème que j'ai est quand le contenu est gzip (par exemple Content-Encoding: gzip). Les données que je reçois via OnDataAvailable sont compressées. J'ai besoin des données non compressées. J'utilise BINDF_PULLDATA | BINDF_GETNEWESTVERSION | BINDF_NOWRITECACHE drapeaux de liaison. J'ai lu quelques articles qui disent qu'il devrait supporter le format gzip.

J'ai d'abord essayé de modifier l'en-tête de requête Accept-Encoding pour indiquer que je ne voulais pas gzip mais que cela ne me convenait pas. Je peux modifier ou ajouter des en-têtes dans BeginningTransaction, mais cela ne change pas Accept-Content. J'ai été capable de changer l'User-Agent, et j'ai été capable d'ajouter un nouvel en-tête, donc le processus fonctionne, mais cela ne remplacerait pas le Contenu Accepté pour une raison quelconque.

L'autre option consiste à décompresser les données moi-même. Dans un test rapide utilisant une bibliothèque gzip C++, j'ai été capable de décompresser le contenu. Donc, cela peut être une option. Si c'est ce que je dois faire, quelle est la meilleure méthode pour le détecter est gzip. J'ai remarqué que j'ai obtenu un événement OnProgress avec BINDSTATUS_MIMETYPEAVAILABLE et le texte défini sur "application/x-gzip-compressed". Est-ce ainsi que je devrais le détecter?

Vous cherchez une solution pour contourner ce problème! Je veux rester avec URLOpenPullStream. C'est un produit qui a été publié et qui souhaite garder les changements au minimum.

Answer 1

Je vais répondre à ma propre question après plus de recherches. Il semble que le site avec lequel je rencontre le problème renvoie quelque chose d'incorrect, IE, FF et URLOpenPullStream ne le reconnaissent pas comme contenu gzip valide. Les en-têtes semblent être bien, par ex.

    HTTP/1.1 200 OK 
    Content-Type: text/html; charset=iso-8859-1 
    Content-Encoding: none 
    Server: Microsoft-IIS/6.0 
    MSNSERVER: H: COL102-W41 V: 15.4.317.921 D: 2010-09-21T20:29:43 
    Vary: Accept-Encoding 
    Content-Encoding: gzip 
    Content-Length: 4258 
    Date: Wed, 27 Oct 2010 20:48:15 GMT 
    Connection: keep-alive 
    Set-Cookie: xidseq=4; domain=.live.com; path=/ 
    Set-Cookie: LD=; domain=.live.com; expires=Wed, 27-Oct-2010 19:08:15 GMT; path=/ 
    Cache-Control: no-cache, no-store 
    Pragma: no-cache 
    Expires: -1 
    Expires: -1 

mais URLOpenPullStream juste téléchargé en format compressé brut, IE signale une erreur si vous essayez d'accéder au site, et FF montre ordures. Après avoir effectué un test avec un site qui renvoie un contenu gzip valide, par ex. www.webcompression.org, puis IE, FF et URLOpenPullStream ont bien fonctionné. Donc, il semble que URLOpenPullStream supporte le contenu gzip. Dans ce cas, c'était transparent. Dans OnDataAvailable, j'ai reçu les données non compressées, et dans OnResponse, les en-têtes n'affichaient pas Content-Encoding en tant que gzip.

Malheureusement, cela n'a toujours pas résolu mon problème. J'ai résolu en vérifiant les en-têtes de réponse dans l'événement OnResponse. Si Content-Encoding était gzip, alors j'ai mis un drapeau et quand le téléchargement était terminé, j'ai utilisé les routines zlib gzip pour décompresser le contenu. Cela a semblé fonctionner correctement. Cela devrait convenir à mon cas rare car, en règle générale, je ne devrais jamais recevoir de Content-Encoding: gzip dans les en-têtes OnResponse puisque l'URLOpenPullStream gère la décompression de façon transparente.

Dunno :)