Le site Web IIS envoie plusieurs en-têtes de type de contenu pour les fichiers zip

Question

Nous avons un problème avec un serveur IIS5.

Lorsque certains utilisateurs/navigateurs cliquent pour télécharger des fichiers .zip, le texte binaire charabia rend parfois dans la fenêtre du navigateur. Le comportement souhaité est que le fichier soit téléchargé ou ouvert avec l'application zip associée.

Initialement, nous soupçonnions que le mauvais en-tête de type de contenu était défini sur le fichier. La technologie IIS a confirmé que les fichiers .zip étaient servis par IIS avec le type «application/x-zip-compressed» de type mime.

Toutefois, une inspection des paquets HTTP utilisant Wireshark révèle que les demandes de fichiers zip renvoient deux en-têtes Content-Type.

• Type de contenu: text/html; charset = UTF-8
• Content-Type: application/x-zip-compressé

Toute idée pourquoi IIS envoie deux têtes de type de contenu? Cela ne se produit pas pour les fichiers HTML ou images standards. Cela arrive avec ZIP et PDF.

Y a-t-il un endroit particulier où nous pouvons demander à la technologie IIS de regarder? Ou y a-t-il un fichier de configuration que nous pouvons examiner?

Answer 1

Je crois - et je peux me tromper que l'en-tête http 1.1 envoie des définitions multiples d'en-têtes et le plus spécifique a la priorité. Donc, dans votre exemple ici, il envoie 2 text/html puis application/x-zip-commercial donc le second serait le plus spécifique - si cela ne peut pas être traité sur le client, alors le plus général est utilisé (le premier dans ce cas) -

J'ai lu ce http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html et ce genre de points à ce que vous dites - pas sûr si c'est ce qui se passe réellement cependant.

Bien sûr, je peux être tout à fait tort ici

Answer 2

Assurez-vous que vous n'avez pas des filtres ISAPI ou ASP.net modules HTTP mis en place pour réécrire les en-têtes. S'ils ne vérifient pas si l'en-tête existe déjà, il sera ajouté plutôt que remplacé. Nous avons eu des problèmes il y a quelques temps avec un module d'authentification interne qui ne mettait pas correctement à jour les en-têtes, nous obtenions donc deux en-têtes d'autorisation, un d'IIS et un de notre module.

Answer 3

Quel logiciel a été installé sur le serveur pour fonctionner avec les fichiers .zip? Il looks like IIS sélectionne les traductions MIME à partir du registre, peut-être que le logiciel zip que vous utilisez a enregistré le type MIME. Cela n'explique pas pourquoi IIS répondrait avec deux en-têtes de type de contenu, donc tout filtre ISAPI et autre Mime-table est suspect.

Answer 4

Cela peut être lié à cela knowledge base article. Il est suggéré que IIS peut gzipper le fichier déjà zippé, mais certains navigateurs passent juste directement à une application secondaire vous donnant de mauvaises données (car il a été compressé deux fois). Si vous modifiez le type mime de l'extension zip à application/octet-stream cela peut ne pas arriver.

Answer 5

Il semble qu'il puisse y avoir un problème avec votre configuration d'IIS.Cependant, ce n'est pas possible de dire de votre message si c'est le cas.

Vous pouvez avoir des types MIME configurés sur plusieurs niveaux sur votre IIS. Mes connaissances IIS 5 sont un peu rouillées, autant que je puisse me rappeler ce comportement est le même pour IIS 6. J'ai essayé de simuler cela sur un environnement IIS 6, mais seulement reçu un type mime selon l'en-tête accepté

J'ai mis l'en-tête des fichiers zip sur le site à l'application/x-zip-compressé et le fichier que j'ai mis à explicity

tinyget -srv:dev.24.com -uri:/helloworld.zip -tbLoadSecurity 
WWWConnect::Connect("server.domain.com","80") 
IP = "127.0.0.1:80" 
source port: 1581 

REQUEST: ************** 
GET /helloworld.zip HTTP/1.1 
Host: server.domain.com 
Accept: */* 


RESPONSE: ************** 
HTTP/1.1 200 OK 
Content-Length: 155 
Content-Type: text/html 
Last-Modified: Wed, 29 Apr 2009 08:43:10 GMT 
Accept-Ranges: bytes 
ETag: "747da786a6c8c91:0" 
Server: Microsoft-IIS/6.0 
Date: Wed, 29 Apr 2009 10:47:10 GMT 

PK?? 
? ? ? helloworld.txthello worldPK??¶ 
? ? ?  ?   helloworld.txtPK?? ? ? < 7 ? hello world sample 
WWWConnect::Close("server.domain.com","80") 
closed source port: 1581 

Cependant, je ne me sens pas cela prouve bien. Il soulève cependant quelques questions:

1. Quelle est toutes les cartes de mime qui ont été mis en place sur le serveur (demander à l'administrateur du serveur pour le fichier MetaBase.xml, puis vous pouvez vous assurer qu'il n'a pas manqué un peu paramètre)
2. Ces clients se trouvent-ils sur un réseau sous votre contrôle? Probablement pas, je me demande quel serveur proxy pourrait être assis entre votre serveur et les clients
3. Comment ressemble le journal IIS, pour cette requête, je suis spécifiquement intéressé par l'en-tête Accept. Je me demande ce que fiddler montrera?

Answer 6

J'ai rencontré un problème similaire. Je testais les téléchargements sur IIS 6 et ne comprenais pas pourquoi un fichier zippé appelé test.zip s'affichait sous forme de texte dans IE8 (c'était bien dans d'autres navigateurs, où il serait téléchargé). Puis j'ai réalisé que pour le test j'avais compressé un très petit fichier texte. Ma conjecture est que IE reniflé le fichier, vu le texte (qui était à peu près non compressé en raison de la petite taille) et a décidé qu'il s'agissait de texte brut.

J'ai réessayé avec un fichier plus volumineux et l'invite de téléchargement est apparue OK dans IE8. Peut ne pas être pertinent pour votre cas, mais pensé que je le mentionnerais.

Tim