comment faire pour "Content-encoding gzip deflate" en-tête envoyé par Chrome?

Question

Nous avons un formulaire de connexion HTML simple sur le serveur web de notre appareil embarqué. Le serveur Web est personnalisé en raison de limitations de mémoire importantes. Indépendamment de ces limitations, nous aimons Chrome et aimerions le supporter.

Tous les navigateurs poster une Demande HTTP à notre formulaire de connexion contenant le "nom d'utilisateur = nom_name & password = mypass" chaîne attendue, mais pas Chrome. Au lieu de cela, nous recevons de Chrome une requête "Content-encoding gzip deflate". BTW, par "tous les navigateurs", je veux dire que cela a été testé pour fonctionner correctement sur Internet Explorer versions 9 bêta, 8, 7, 6; Firefox versions 4 beta, 3, 2; Opera 10, 9; Safari 5, 4, 3; En référence à la section "14.2 Accept Charset" de http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html de w3.org, nous avons essayé de renvoyer un code HTTP 406 pour indiquer que ce serveur ne supporte pas cet encodage dans l'espoir que Chrome réessayerait et publierait les chaînes attendues de la manière standard. Le code 406 renvoyé par le serveur Web est clairement affiché dans la fenêtre "Inspect Element" de Chrome, mais il semble être traité par Chrome comme un code d'erreur, et aucune autre demande n'est envoyée au serveur Web. "Échec de la connexion." Nous avons également essayé les codes de retour HTTP 405 et 200, même résultat. Y at-il un moyen de contourner ce problème avec le JavaScript côté client qui empêchera Chrome d'envoyer la requête "Content-encoding gzip deflate", ou avec une réponse côté serveur qui expliquera bien à Chrome nous don Ne faites pas de gzip, envoyez-le nous régulièrement?

Nous avons essayé de poster sur le forum de dépannage Google Chrome sans réponse.

Toute aide serait grandement appréciée!

Meilleures salutations, Bert

Answer 1

On dirait que lors de l'utilisation de chrome pour faire un post à un serveur la première fois, par défaut chrome à l'aide d'un encodage gzip. Assez étrange. La solution la plus simple est de simplement placer votre nom d'utilisateur/pass comme paramètres GET, et lors de l'envoi de la réponse, tant que vous n'envoyez pas de codage de contenu gzip, chrome devrait commencer à utiliser des messages non gzip à partir de ce point. Espérons que cela fonctionne?

Answer 2

J'ai testé cela un peu avec un simple script Python qui a imprimé sur stdout. Je pensais que je recevais le même problème, mais ensuite j'ai réalisé que j'oubliais juste de rincer stdout. Il semble que Chrome envoie toujours la requête jusqu'à la fin des en-têtes avant d'envoyer le contenu de la demande, et vous devez utiliser un second appel recv pour obtenir les données POST. En revanche, la totalité de la requête Firefox est renvoyée dans un seul appel recv.

Answer 3

Vous recherchez dans la mauvaise section le code d'erreur: Section 14.11 de la RFC 2616 spécifie que vous envoyez un 415 (type de support non pris en charge) si vous ne pouvez pas gérer le Content-Encoding.