appengine, urlfetch et l'en-tête content-length

Question

J'ai une application Google Appengine demandant des pages d'un autre serveur utilisant les POST urllib2. J'ai récemment activé la compression gzip sur l'autre serveur exécutant Apache2, et les demandes de page Appengine ont commencé à échouer sur key-error, indiquant que 'content-length' ne se trouve pas dans les en-têtes.

Je ne déclare pas explicitement gzip comme un encodage accepté dans mes requêtes d'Appengine, mais il est possible que Appengine ajoute cet en-tête. Googling n'a pas révélé d'indication claire que l'urlfetch d'Appengine ajoute implicitement un en-tête pour accepter le codage gzip. Si je me souviens bien, Apache2 omet les en-têtes de longueur de contenu lorsque la réponse est compressée, mais cela ne devrait pas affecter les réponses non compressées du même serveur.

Quelqu'un a-t-il un aperçu de ce qui se passe, pourquoi l'en-tête content-length est-il omis?

Answer 1

Selon ce fil: http://groups.google.com/group/google-appengine-java/browse_thread/thread/5c5f2a7e2d2beadc?pli=1) sur un newsgroup Appengine Java, Google ne définit généralement la « Accept-Encoding: gzip » en-tête sur les demandes de UrlFetch et décompresse (ungzips) l'entrée avant la remise des données au scénario. Apparemment, Appengine ajoute implicitement un en-tête gzip accept-encoding: sur les demandes d'accès à Internet, et décompresse la réponse, mais n'insère pas de longueur de contenu dans les en-têtes pour la taille de données décompressée. Donc, si le serveur externe fournit des réponses gzippées, le résultat net pour le script Appengine (après tout le comportement de pré-traitement et de post-traitement par Appengine décrit ci-dessus) est la perte de l'en-tête content-length.