1

IIS5 サーバーに問題があります。

特定のユーザー/ブラウザーがクリックして .zip ファイルをダウンロードすると、ブラウザー ウィンドウに意味不明なバイナリ テキストが表示されることがあります。望ましい動作は、ファイルをダウンロードするか、関連する zip アプリケーションで開くことです。

当初、ファイルに間違った content-type ヘッダーが設定されているのではないかと疑っていました。IIS の技術者は、MIME タイプ「application/x-zip-compressed」の .zip ファイルが IIS によって提供されていることを確認しました。

ただし、Wireshark を使用して HTTP パケットを検査すると、zip ファイルの要求が2 つのContent-Type ヘッダーを返すことがわかります。

  • コンテンツ タイプ: テキスト/html; 文字セット=UTF-8
  • コンテンツ タイプ: application/x-zip-compressed

IIS が2 つのcontent-type ヘッダーを送信する理由は何ですか? これは、通常の HTML ファイルや画像ファイルでは発生しません。ZIP と PDF で発生します。

IIS 技術者に確認を依頼できる特定の場所はありますか? または、調査できる構成ファイルはありますか?

4

6 に答える 6

0

.zipファイルを操作するためにサーバーにインストールされているソフトウェアは何ですか？IISがレジストリからMIME変換を取得しているようです。おそらく、使用しているzipソフトウェアがMIMEタイプを登録しています。これは、IISが2つのコンテンツタイプヘッダーで応答する理由を説明していないため、ISAPIフィルターやその他のMimeテーブルが疑われます。

于 2009-04-25T18:43:02.320 に答える
0

IISの構成に問題があるようです。ただし、これが当てはまるかどうかを投稿から判断することはできません。

IISの複数のレベルでmimeタイプを構成できます。私のIIS5の知識は、この動作がIIS 6でも同じであることを思い出す限り、少し錆びています。IIS6環境でこれをシミュレートしようとしましたが、受け入れられたヘッダーに応じて1つのmimeタイプしか受信しませんでした。

サイト上のzipファイルのヘッダーをapplication/x-zip-compressedに設定し、明示的に設定したファイルのヘッダーを

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

しかし、私はこれがあまり証明されているとは感じていません。ただし、いくつかの疑問が生じます。

  1. サーバー上にセットアップされているすべてのmimeマップは何ですか（サーバー管理者にmetabase.xmlファイルを要求すると、サーバー管理者がいくつかの設定を見逃していないことを確認できます）
  2. それらのクライアントは、あなたの管理下にあるネットワーク上にありますか？おそらくそうではないでしょう、私はあなたのサーバーとクライアントの間にどんなプロキシサーバーが置かれているのだろうかと思います
  3. IISログはどのように表示されますか。その要求に対して、Acceptヘッダーに特に関心があります。
  4. フィドラーは何を表示するのだろうか？
于 2009-04-29T11:09:50.720 に答える
0

同様の問題が発生しました。IIS 6 でダウンロードをテストしていたのですが、test.zip という圧縮ファイルが IE8 でテキストとして表示される理由がわかりませんでした (他のブラウザーでは問題なくダウンロードできました)。

その後、テストのために非常に小さなテキスト ファイルを圧縮したことに気付きました。私の推測では、IE はファイルを盗聴し、テキスト (サイズが小さいためほとんど圧縮されていません) を見て、それがプレーン テキストであると判断したのです。

より大きなファイルで再試行したところ、IE8 でダウンロード プロンプトが正常に表示されました。

あなたのケースには関係ないかもしれませんが、私はそれについて言及したいと思いました。

ティム

于 2009-08-03T09:14:32.640 に答える
0

これは、このナレッジベースの記事に関連している可能性があります。 これは、IIS が既に圧縮されたファイルを gzip 圧縮している可能性があることを示唆していますが、一部のブラウザは、2 回圧縮されているため、セカンダリ アプリケーションに直接バック パスするだけで、不適切なデータを提供します。zip 拡張子の MIME タイプをapplication/octet-streamに変更すると、これは発生しない可能性があります。

于 2009-04-28T23:28:28.223 に答える
0

http 1.1 ヘッダーが複数のヘッダー定義を送信し、最も具体的なものが優先されるというのは間違っているかもしれません。

したがって、ここの例では、2 つの text/html を送信してから application/x-zip-commercial を送信しているため、2 番目のものが最も具体的になります。クライアントで処理できない場合は、より一般的なものが使用されます (最初のものが使用されます)。この場合 ） -

私はこのhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlを読んで、あなたが言っていることを指摘していますが、これが実際に起こっているかどうかはわかりません。

もちろん、私はここで完全に間違っているかもしれません

于 2009-04-23T22:47:18.567 に答える