えむけいさん、
MIMEタイプ／拡張子の他、一定のContent-length以上でオプションにすればいいのかもしれませんね。
2連続の場合は本来2番目の方で完全な応答を得ているのかもしれないのにそれが判定できていないわけですから、矛盾はしないと思います。
>それとは別に、2連続にならないようにするにはプロクシが適切な応答ヘッダを出せばいいとかいう話でしょうか？
方法は問いません。ただプロキシが2連続でWebサーバへリクエストを転送しないようにすれば帯域の節約になるとは思いますが。
上記の要望とは矛盾するようですが、特定のMIMEタイプや拡張子を持つキャッシュファイルは完全な応答を受け取ったら削除するようなオプションはつけられないでしょうか? 個人で使っていると2度同じファイルをダウンロードすることってまずないので…。
「完全な応答」と条件をつけているのは、途中で切られた場合にはそこから再開したいからです。
えむけいさん、
現状ではキャッシュファイルを直接作っていくため同一リソースへの連続リクエストがあると最初のリクエスト対する応答だけがキャッシュの対象になってしまいます。
キャッシュファイルを一時ファイルにしてリネーム時に判断をいれれば完全な内容が残せると思います。
それとは別に、2連続にならないようにするにはプロクシが適切な応答ヘッダを出せばいいとかいう話でしょうか？
前回の報告で触れたIE5.5で同じリクエストが2連続で発行される現象ですが、どうやらIE5.01でも発生するようです。ファイルをダウンロードするときに発生します。
この現象が発生すると、実際のアーカイブファイルのサイズにかかわらず、キャッシュには最初の数KBしか残りません(2回目のリクエストの応答を受け取ると、IEが1回目のリクエストをさっさと切ってしまうようです)。この場合でもキャッシュに完全な内容が残せるように対処できないでしょうか?
えむけいさん、
If-Range の件、了解しました。
If-Range か If-Unmodified-Since で同じものかどうか確認を入れているつもりでしたが、抜けていたようです。
キャッシュに不正なデータができる件の追加報告です。
要求前にキャッシュに8160バイトの途中切れしたデータがあって、ヘッダは
----------------------------------------------------------------------というものでした。このときブラウザから来たリクエストが
HTTP/1.1 200 OK
Date: Sat, 20 May 2000 17:44:00 GMT
Server: Apache/1.3.12 (Unix)
Last-Modified: Sat, 20 May 2000 16:54:52 GMT
ETag: "c19a-707122-3926c35c"
Accept-Ranges: bytes
Content-Length: 7368994
Connection: close
Content-Type: application/zip
X-Pad: avoid browser bug
----------------------------------------------------------------------
----------------------------------------------------------------------で、サーバに転送されたデータが
GET http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32.zip HTTP/1.0
Accept: */*
Accept-Language: ja,en;q=0.5
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; WindowsNT 5.0)
Host: ftp.mozilla.org
Proxy-Connection: Keep-Alive
----------------------------------------------------------------------
----------------------------------------------------------------------というものです。ご覧のとおりRangeがあるのにIf-Rangeがないので、
GET /pub/mozilla/nightly/latest/mozilla-win32.zip HTTP/1.0
Accept: */*
Accept-Language: ja,en;q=0.5
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; WindowsNT 5.0) via proxy gateway AnWeb/1.28
Via: 1.0 pcg-803
Host: ftp.mozilla.org
Range: bytes=8160-
----------------------------------------------------------------------
----------------------------------------------------------------------サーバのデータがキャッシュされて以降更新されている(ETagが違う)のに、キャッシュにあるデータとこの応答とが組み合わせられて、不正なデータになってしまうようです。
HTTP/1.1 206 Partial Content
Date: Sat, 27 May 2000 09:25:28 GMT
Server: Apache/1.3.12 (Unix)
Last-Modified: Sat, 27 May 2000 04:47:08 GMT
ETag: "ca53-6ed073-392f534c"
Accept-Ranges: bytes
Content-Length: 7254163
Content-Range: bytes 8160-7262322/7262323
Connection: close
Content-Type: application/zip
----------------------------------------------------------------------
----------------------------------------------------------------------という、Acceptだけが違うまったく同じ要求を繰り返しています。前回完全ダウンロードしたはずなのにキャッシュに8160バイトしか残っていなかったことと何か関係あるかもしれません。
GET http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32.zip HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: ja,en;q=0.5
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; WindowsNT 5.0)
Host: ftp.mozilla.org
Proxy-Connection: Keep-Alive
----------------------------------------------------------------------
えむけいさん、
時間があったら私もやってみますが、症状がはっきりしたらまたお知らせください。
一見レジュームできているように見えるのですが、実際にダウンロードしたファイルが壊れて解凍できなくなってしまうらしいことが判明しました。もうちょっと調べてみます。
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32.zip
をAnHTTPDのプロキシ経由でダウンロードしていて途中で切られたとき、再度ダウンロードを試みるとなぜか最初からやり直しになってしまいます。調べようと思ってtrace.logを取ったりするとなぜかレジュームできてしまうので原因不明です。