web-dev-qa-db-ja.com

サイトマップファイルが二重に圧縮される

XMLサイトマップを生成してファイルsitemap.xml.gz-gzipで圧縮されたXMLファイルに書き込むスクリプトがあります。このファイルは間違いなく正しく書き込まれています。FTP経由でダウンロードするときはすべて良いです。

ただし、サイトから（HTTPを介して）ファイルを直接ダウンロードすると、結果のファイルが二重に圧縮されているように見えます。ファイルを解凍すると、sitemap.xmlファイルはバイナリファイルです。名前をsitemap2.xml.gzに変更して再度解凍すると、真のXMLファイルが取得されます。

そのため、サーバー（Apache2）は何らかの理由で.gzファイルを取得し、再びgzip圧縮で提供していると思います。ファイルのヘッダーは次のように戻ります。

Status: HTTP/1.1 200 OK
Date: Mon, 16 Jul 2012 00:00:47 GMT 
Server: Apache  
Last-Modified: Sun, 15 Jul 2012 23:35:26 GMT    
ETag: "89fff2-3bc46-4c4e6c48deb80"  
Accept-Ranges: bytes    
Vary: Accept-Encoding   
Content-Encoding: gzip  
Connection: close   
Transfer-Encoding: chunked  
Content-Type: application/x-gzip

私のhttpd.confにはこれがあります：

# compress all text & html:
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml text/css text/javascript application/x-javascript application/javascript

私のVirtualHost宣言には、いくつかのmod書き換えのものしかありません。

Apacheがこのファイルのgzipヘッダーを送信しているのはなぜでしょうか？

PDATE：AddOutputFilterByType行からapplication/xmlエントリを削除しました。ファイルは他のバイナリファイルと同様に正常にダウンロードされるようになりました。ただし、現在の問題は、通常の.xmlファイルがgzipで送信されなくなったことです。

したがって、サーバーは、ヘッダー.xml.gzで送信しても、application/xmlファイルをapplication/x-gzipとして解析する必要があると判断しているようです。

また、/etc/mime-typesファイルをチェックしましたが、gzipのエントリがなく、上部に次のコメントがあります。

注：「gzip」、「bzip」、「compress」などの圧縮スキームは、実際には「mime-types」ではありません。これらは「エンコーディング」であるため、拡張子をマッピングするために、このファイルにnotエントリが必要です。エンコードされたファイルの「MIMEタイプ」とは、エンコードの種類ではなく、エンコードされたデータの種類を指します。

apachehttp-headersxml-sitemapgzip
5
DisgruntledGoat

@ cyberx86の引用 ServerFaultで （誰が投票するべきか）：

.xml.gzファイルタイプは、xmlファイルとして定義することができます（たとえば、filesmatchブロックにforcetypeを使用）-これにより、Apacheは上記のタイプに一致します。

その上に例外を追加することでそれを回避できると思います：

SetEnvIfNoCase Request_URI ".xml.gz$" no-gzip dont-vary

3
Su'