もじら組フォーラム

(環境: WinXP SP3/Firefox3.0)

以下のサイトのトップ
http://www.emily-garden.net/
を表示させようとしますと
「内容符号化 (Contnet-Encoding) に問題があります」と
表示されます。（トップページ以外は正常です）
キャッシュの削除をしたり、
アドオン「Web Developer」でキャッシュの無効化すると
正常に表示されます。

また、キャッシュを全く変更せずに
http://www.emily-garden.net/index.html
を表示させますと正常に表示されます。
http://www.emily-garden.net/とhttp://www.emily-garden.net/index.htmlは、同じ内容です。

このサイトは、私が製作しているサイトでサーバ側も特に異常がありません。

そこで、アドオン「Live HTTP headers」でHTTPヘッダーを表示させますと
１）「内容符号化 (Contnet-Encoding) に問題があります」の時のヘッダー
２）キャッシュを無効化して「再試行」をした場合のHTTPヘッダー
（文末にヘッダー詳細を記載しています）
のような結果になりました。

キャッシュが働いていると、Range:が付与され、サーバの応答がおかしくなっているのかと思うのですが、バグなのでしょうか？それとも、何か設定がおかしいのでしょうか？

環境は、WinXP SP3 FireFox3.0.1（3.0.0でも同じ現象でした）
また、時折、キャッシュを変更しないでも、正常に表示されることもあります。ですので、すべての人に問題があるわけではないとは思うのですが、サイト側のHTMLの問題なのか？Firefoxの設定なのか？何が問題なのかさっぱり分かりません。よろしくお願いします。

１）「内容符号化 (Contnet-Encoding) に問題があります」と
表示されたときのHTTPヘッダー
----------------------------------------------------------
http://www.emily-garden.net/

GET / HTTP/1.1
Host: www.emily-garden.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.emily-garden.net/books/628.html
Cookie: PHPSESSID=il1dmmnaj6u6vn7aj0uah18mf3
Range: bytes=3982-
If-Range: "98c1b9-5384-487dddd6"

HTTP/1.x 206 Partial Content
Date: Fri, 18 Jul 2008 01:56:04 GMT
Server: Apache
Last-Modified: Wed, 16 Jul 2008 11:39:02 GMT
Etag: "98c1b9-5384-487dddd6"
Accept-Ranges: bytes
Content-Length: 17398
Content-Range: bytes 3982-21379/21380
Connection: close
Content-Type: text/html
----------------------------------------------------------

２）アドオン「Web Developer」でキャッシュの無効化をして
「再試行」をした場合のHTTPヘッダー
----------------------------------------------------------
http://www.emily-garden.net/

GET / HTTP/1.1
Host: www.emily-garden.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.emily-garden.net/books/628.html
Cookie: PHPSESSID=il1dmmnaj6u6vn7aj0uah18mf3

HTTP/1.x 200 OK
Date: Fri, 18 Jul 2008 01:56:18 GMT
Server: Apache
Last-Modified: Wed, 16 Jul 2008 11:39:02 GMT
Etag: "98c1b9-5384-487dddd6"
Accept-Ranges: bytes
Connection: close
Content-Type: text/html
Content-Encoding: gzip
Content-Length: 4055
----------------------------------------------------------

(環境: WinXP SP3/SeaMonkey1.1)

(1) 最初、以下のデータが送られ、
> Etag: "98c1b9-5384-487dddd6", Accept-Ranges: bytes
> Content-Type: text/html, Content-Encoding: gzip, Content-Length: 4055
>(Content-Length:は、実体の長さ(解凍後の長さ)のはずだが、圧縮時の長さを返しているような気が...)
(2) その後、更新が入っているので304ではなく200が返った時に、
3981バイト受け取った時点で、エラーが起こったとか中止された、とかがあり、
(3) 次にアクセスした時に、先頭の部分はすでにキャッシュにあるので、
> Range: bytes=3982-
> If-Range: "98c1b9-5384-487dddd6"
でリクエストがだされ、
(4) (2)の時点以降の更新が入っていないので、サーバーが以下のデータを返してきて、
> Etag: "98c1b9-5384-487dddd6", Accept-Ranges: bytes
> Content-Length: 17398, Content-Range: bytes 3982-21379/21380, Content-Type: text/html
> (gzipをかけていない状態のindex.htmlの3982バイト目以降のデータ）
(5) 「(2)のデータ＋(4)のデータ」を「Content-Encoding:gzipで送られた全体のデータ」として処理しようとしてエラー、
ということのように見えます。

Fx 3で、ダウンロードの中断・再開ができるようにRange:を使うように変えたため、ということのように思えます。
結構な頻度で起こっているようですが、4055バイトのデータの送受信中にたまたまエラー、というのは、滅多にないことのような気が...
モバイル環境でのアクセスとか、たかだか4055バイトのデータでも途中でのエラーが起こり得る環境からアクセスした後の話、ですか？
ロード開始直後に「中止」を押したあとに起こる、というようなことはないですか？

Content-Encoding:gzipで送る設定の時には明示的にAccept-Ranges:noneを送るとか、Content-Encoding:gzipで送る設定なんだからRange:でリクエストが来たらエラーを返す、などをしてくれないサーバーが悪いのか、
Content-Encoding:gzipで送られてきているにも関わらず、Range:でリクエストするほうが悪いのか...

(3)に対する(4)の応答自体は、「実体(圧縮されていないindex.html)の3982バイト目以降全部」というリクエストへの応答ですから、「正しい」のだと思います。
多分、Content-Encoding:gzipで送られたデータの一部しかキャッシュに存在しない時に、キャッシュを無効にせずに、Range:でリクエストしたFxが悪い、ということでしょうね。

(環境: WinXP SP3/SeaMonkey1.1)

bugzilla.mozilla.orgを"zip range"で検索したら、全く同じ現象に関するバグがありました。
> Bug 247334 Handle unexpected 206 responses better [mod_gzip: range request on compressed document is returned uncompressed with same ETag]
> https://bugzilla.mozilla.org/show_bug.cgi?id=247334
> "range:"で検索していたので、見つけられなかった...(^^;
サーバー側の応答が悪い、ということのようです。

https://bugzilla.mozilla.org/show_bug.cgi?id=247334#c4 には、以下のように書いてあります。
> 2004-10-29 14:12:19 PDT
> A standard Apache 1.3 with mod_gzip will reproduce this problem.
> For blogspot, we patched Apache to never return Accept-Ranges: bytes.
> Thus, Mozilla will never attempt a range fetch,
> and (thus) never trigger the busted behavior of mod_gzip.

お使いのApacheのバージョンは？
Apacheの設定やPHPで、常に"Accept-Ranges: bytes"を返すようにしている？

(環境: WinXP SP3/Firefox3.0)

ご回答ありがとうございます。

> モバイル環境でのアクセスとか、たかだか4055バイトのデータでも途中での
> エラーが起こり得る環境からアクセスした後の話、ですか？
いえ、FTTHの自宅で普通に操作した結果です。

> ロード開始直後に「中止」を押したあとに起こる、
> というようなことはないですか？
中止は一度もしていないです。

> サーバー側の応答が悪い、ということのようです。
バグとして処理されていないということですか・・・。
サーバ側かHTML側で何らかの対応をしなければならないということですね・・・

> お使いのApacheのバージョンは？
coreserverをレンタルしておりましてApacheは、1.3.37となっております。
http://www.value-domain.com/coreip.php?action=all
全サーバ同じようです。

> Apacheの設定やPHPで、常に"Accept-Ranges: bytes"を返すようにしている？
すみません。レンタルしているため、詳細が分かりません。phpでphpinfo()を実行すれば分かる内容でしょうか？apacheという項目はあるのですがどれを見てよいか分からない状態です。

> 結構な頻度で起こっているようですが、
私のPC環境では、頻繁に起こっています。
WADAさんが見ても同じ状況になっているのでしょうか？私だけの特殊な現状かもと思ってもいたのですが、Fx3を使用されている方に頻繁に発生するようであればすごく困ってしまいます。

(環境: WinXP SP3/SeaMonkey1.1)

(1) http://www.emily-garden.net/favicon.icoが、Location: http://www.emily-garden.net/ を返してきます。
>GET /favicon.ico HTTP/1.1
> Host: www.emily-garden.net
>(snip)
> HTTP/1.x 302 Found
> Location: http://www.emily-garden.net/
従って、Fx 3ではbrowser.chrome.favicons=trueがデフォールトなので、http://www.emily-garden.net/ に対する「2重のHTTP GET」が起こり得ます。
これが、http://www.emily-garden.net/ のほうの、Range:でのHTTP GETリクエストと、その結果としての、If-Range指定にも関わらず同じEtag・非圧縮データの206レスポンス、の引鉄になっている可能性があります。

(2) http://www.emily-garden.net/index.html をhtmllintでチェックすると、「重要度９」のエラーが3箇所に対してでます。
> http://openlab.ring.gr.jp/k16/htmllint/htmllint.html

> 9: line 3: <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="〜"> で CHARSET が指定されるより前に非ASCII文字が含まれています。
> 9: line 36: <FORM> を 31行目の <TR>〜</TR> 内に書くことはできません
> 9: line 79: <STYLE> を 63行目の <TD>〜</TD> 内に書くことはできません。

line 3については厳密な意味での文法違反ではないのですが、line 3の問題があると、Firefoxの場合には、処理すべき文字コードが途中で変わることによって2重のHTTP GETがでる、という現象が起こり得ます。
このサイトは現在Content-Encoding:gzipで返すので、line 3の問題に起因する「2重のHTTP GET」は起こらないはずですが、サーバー側のなんらかの変更によりContent-Encoding:gzipなしで返すようになると、Firefoxによる「2重のHTTP GET」を引き起こす可能性がでてきます。
このサイトの場合は、静的なHTMLファイルのようなので、たとえ「2重のHTTP GET」になっても問題は無いはずですが(表示/ページのソース、の時と同じこと)、PHPスクリプトでPHPのセッション管理などを利用してMySQLのDB更新、というようなケースでは、PHPスクリプト側のきちんとした「2重GET/POST」対策がなされていないと、問題を引き起こす可能性がでてきます。
ご注意を。

(環境: WinXP SP3/Firefox3.0)

確かに全く問題がないとは思っていないのですが、表示が全く出来なくなるほど問題があるとは思っていませんでした。（サイトを何度も改良しているため、継ぎ接ぎな部分があります）

> (2) http://www.emily-garden.net/index.html をhtmllintでチェックすると、「重要度９」のエラーが3箇所に対してでます。
>>http://openlab.ring.gr.jp/k16/htmllint/htmllint.html
>
>>9: line 3: <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="〜"> で CHARSET が指定されるより前に非ASCII文字が含まれています。
>>9: line 36: <FORM> を 31行目の <TR>〜</TR> 内に書くことはできません
>>9: line 79: <STYLE> を 63行目の <TD>〜</TD> 内に書くことはできません。

<title>タグを下にづらして、<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="〜">を上に上げました。他のタグも、エラーに指示に従い、少し変更してみると「内容符号化 (Contnet-Encoding) に問題があります」の表示がなくなりました。何が原因か分かりませんが、これで少し様子をみようと思います。ありがとうございます。

> 従って、Fx 3ではbrowser.chrome.favicons=trueがデフォールトなので、
> http://www.emily-garden.net/ に対する「2重のHTTP GET」が起こり得ます。
ファイルがない場合、.htaccessで、すべてトップページへリダイレクトさせるようにしています。一応、favicon.icoを仮にUPLOADしましたので、ここでの「2重のHTTP GET」はおこらなくなったのではないかと思います。

このサイトは、基本的には静的なHTMLですが、買い物かごは、phpで動作してますので、対策をしようと思います。ご忠告ありがとうございます。

(環境: WinXP SP3/SeaMonkey1.1)

> ファイルがない場合、.htaccessで、すべてトップページへリダイレクトさせるようにしています。

その理由は？

少なくとも２つの問題があります。
(1) index.html をリネームすると、リダイレクトの無限ループ状態になり得る。
Apache(あるいはApacheの設定)が自分自身へのリダイレクトを許さないとか、
302は「異なるLocationへのリダイレクト」とHTTP 1.xで定義されているので、Apacheがそれは返さないとか、Fx 3が不正なLocation:として無視、などがあって、
実際には、無限ループ状態になってToo many redirectなどに至る、というようなことは起こらないかも知れませんが、
メインテナンス中のちょっとしたミスが、メインテナンス時の確認作業の大きな障害につながる可能性がでてきます。
(2) 更新作業の中で、<script src="non-existent-file-xxx.js">とか<img src="non-existent-file-xxx.jpg">ができてしまった時、確認作業時に、最悪、その数だけのHTTP GETが出されることになります。
これが、Range:/If-Range:"etag-data"でのリクエストの原因の一つの「部分的なキャッシュデータの状態」を引き起こしたのかもしれません。

(A) URLでのリダイレクトでなく、ファイル(index.html)で指定する。
(index.htmlがない場合、Apacheがそれを検知できるので、「無限ループ」には陥らない)
(B) カストマイズされた404ページとしてのindex.htmlは、.html/.htmなどの拡張子の場合のみにとどめ、.jpgなどはダミーのファイルを指定しておく。
(たとえば、"Not found"という表示の.jpgを作っておけば、メインテナンス時のエラーなどが簡単に目に見えるようになる)
(C) 本当に必要なものを除きApacheにおまかせで、できるだけ余計なデータが返らないようにする。
あたりのほうがいいのではないですか？

(環境: WinXP SP3/SeaMonkey1.1)

>>お使いのApacheのバージョンは？
> coreserverをレンタルしておりましてApacheは、1.3.37となっております。
> http://www.value-domain.com/coreip.php?action=all
> 全サーバ同じようです。

参照したバグの中でポイントしている他のバグの中で、Apache 2ではmod-deflateを使用するので問題が起こらない、といっています。
「Apache 2」＋「mod-deflate」では、自動圧縮で送る時に、圧縮前の状態でのEtagとは異なるEtagを生成しているので、Range:/If-Range:でリクエストが来た時には、圧縮前の状態のEtagと比較することになり、200＋圧縮した全データ＋Content-Encoding:deflateが返されるので問題は起こらない、のかもしれないですね。
また、Apache 1.3では注意を喚起する文書が必要か？、などといっています。
Apache 1.3では、自動的に圧縮してContent-Encoding:gzipで返す設定の時には、
今回のケースの時に、仕様通りに圧縮版のデータの一部を206で返すようにする、
あるいは、200＋圧縮した全データ返すようにする、などの追加の設定・処置をしない限り、
Accept-Ranges:bytesを送ってはいけない、あるいはAccept-Ranges:noneを送らなくてはいけない、ということのように見えます。
HTTPの仕様では、Accept-Ranges:bytesが返ってこなくてもRange:/If-Range:を送って構わないのですが、普通のブラウザーはAccept-Ranges:bytesがない時にはRange:/If-Range:でのリクエストをださないようなので、Accept-Ranges:bytesを返さなければＯＫのようです。

>>Apacheの設定やPHPで、常に"Accept-Ranges: bytes"を返すようにしている？
> すみません。レンタルしているため、詳細が分かりません。

別のサブスレッドで、「.htaccessでファイルが無い時はトップページにリダイレクト」とおっしゃっているので、以下については、レンタルサーバー(おそらくApacheのVirtual Server)内の.htaccessでの設定ではなく、Apache本体側の設定(httpd.conf)で行っているのでしょうね。
(A) 常にAccept-Ranges:bytesを返す (巨大なPDFや画像・動画などの中断したダウンロードの再開ができるようにするため)
(B) text/htmlの時に、自動的にgzip圧縮してContent-Encoding:gzipで返す
初めは(A)だけだったのが、パフォーマンスの向上ということで(B)も追加設定したんじゃないかな。

.htaccessで、
> Header unset Accept-Ranges
>あるいは
> Header set Accept-Ranges none
を指定した時、.html/.css/.js/.jpg/.pdfなどは、どのようなフローで送られてきますか？

(環境: WinXP SP3/Firefox3.0)

色々、ミスがあると認識いたしました。

> (A) URLでのリダイレクトでなく、ファイル(index.html)で指定する。
ネットで検索してみたら、URLでの指定は、初歩的に薦められないことだったんですね。
> (B) カストマイズされた404ページとしてのindex.htmlは、
> .html/.htmなどの拡張子の場合のみにとどめ、
> .jpgなどはダミーのファイルを指定しておく。
<Files ~ "\.html$">
ErrorDocument 404 /index.html
</Files>
に変更します。
> (C) 本当に必要なものを除きApacheにおまかせで、
> できるだけ余計なデータが返らないようにする。あたりのほうが
> いいのではないですか？
そうですね。検索エンジンから削除したページに来た人も逃したくないという思いがあり、トップへリダイレクトさせていたのですが、htaccess自体をなくすことも考えます（サーバの負荷が減るでしょうし）。

ありがとうございます。

(環境: WinXP SP3/Firefox3.0)

色々とご返信ありがとうございます。
>
> .htaccessで、
>>Header unset Accept-Ranges
> >あるいは
>>Header set Accept-Ranges none
> を指定した時、.html/.css/.js/.jpg/.pdfなどは、どのようなフローで
> 送られてきますか？
回答遅れましたが試してみました。

以前の状況を復元できなくなってしまったので
試した意味はあまりないかもしれませんが、
普通にすると以下のようになり
----------------------------------------------------------
http://www.emily-garden.net/

GET / HTTP/1.1
Host: www.emily-garden.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.emily-garden.net/craft/
Cookie: PHPSESSID=vpqkq8rrhh376mmhiae4gbnm90
If-Modified-Since: Tue, 22 Jul 2008 04:36:23 GMT
If-None-Match: "98c1b9-542d-488563c7"

HTTP/1.x 304 Not Modified
Date: Wed, 23 Jul 2008 18:01:26 GMT
Server: Apache
Connection: close
Etag: "98c1b9-542d-488563c7"
----------------------------------------------------------

「Accept-Ranges: bytes」が出てこないのですが
同じHTMLを上書きしてみると

----------------------------------------------------------
http://www.emily-garden.net/

GET / HTTP/1.1
Host: www.emily-garden.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.emily-garden.net/craft/
Cookie: PHPSESSID=vpqkq8rrhh376mmhiae4gbnm90
If-Modified-Since: Tue, 22 Jul 2008 04:36:23 GMT
If-None-Match: "98c1b9-542d-488563c7"
Cache-Control: max-age=0

HTTP/1.x 200 OK
Date: Wed, 23 Jul 2008 18:02:07 GMT
Server: Apache
Last-Modified: Wed, 23 Jul 2008 18:02:02 GMT
Etag: "98c1b9-542d-4887721a"
Accept-Ranges: bytes
Connection: close
Content-Type: text/html
Content-Encoding: gzip
Content-Length: 4096
----------------------------------------------------------
上記のようになります。これは、
>>Header unset Accept-Ranges
でも
>>Header set Accept-Ranges none
でも、同じです。
これは、.htaccessでは操作できないようになっているようです。
Accept-Ranges:bytesは常に返すことになりますので、レンタルサーバをしている以上、HTMLで対処するしかないようです。（HTMLの何らかの記述がFx3に、このような動作をする要因があるとは思うのですが、色々な要因が重なっておこるようなので、できるだけ正しいHTMLを記述するように心がけるしかないようです）