お世話になります。 日立システムの松本と申します。 DeleGate 9.7.6 (Windows)を利用させて頂いています。 DelaGateをhttpのキャッシュサーバとして使用していますが、 DeleGateのIf-Modified-Sinceの扱いについて確認させて頂きたく投稿させて頂きました。 実は以下の様な現象になっており、かなり困っています。 お助け下さい。 【現象】 クライアントのキャッシュに存在せず、且つDeleGateのキャッシュには存在するコンテンツに対して、DeleGateがクライアントからGETリクエスト を受けて目的のWEBサーバに対するGETリクエストを行うと、DeleGateのキャッシュが最新であっても目的のWebサーバからはDeleGateに対して は200で実体が返ってきます。(304で返ってきて欲しい) 目的のWebサーバは社内のイントラ業務で使用しており、主としてJAVAのアプレット配信を行っています。クライアント台数が多く、個々のクライアント が利用するアプレットは同じであるため、Webサーバ及びWebサーバ〜クライアント間のネットワーク負荷軽減の目的で、クライアントセグメント上に DeleGateのサーバを設置していますが、個々のクライアントが自キャッシュに存在しないコンテンツのリクエストを行う度にDeleGate側のキャッシュが 最新であるにも係わらず、Webサーバ〜DeleGate間で200の実体転送が行われるため、DeleGateのキャッシュが有効に利用できていません。 【調査状況】 DeleGateがクライアントからIf-Modified-Sinceの無いGETリクエストを受けた場合、DeleGateが目的のWebサーバに対してもIf-Modified-Sinceを付けず にリクエストしている様に思えます(DeleGate〜Webサーバ間のキャプチャが取れなかったため創造の域です。すみません)が、 どうも当現象となるのがJAVAの場合のみの様にも見受けられるのです。(HTML、画像、Curlなどでは起きていない様に見えるのですがまだザクッと見た だけですのではっきりしたことは判りません。継続して切り分け中です) JAVAはブラウザ(IE6)のキャッシュではなく、独自のキャッシュを使用していますが、DeleGate側から見ればクライアント内でどこのキャッシュが使われて いるかなどは関係なく、受けたリクエスト内のヘッダで振る舞いが決まるものと思っていますので、単にJAVAコンテンツへのリクエストの出し方が悪いだけ なのか、(初心者で申しわけありません)それともDeleGateのそもそもの仕様なのかについて、まずは切り分けを頂ければ有り難く思います。 【クライアントキャッシュに無い場合のDeleGateログ】 01/24 11:55:53.06 [3860] 52+20: (0) accepted [43] -@[10.9.16.86]v99he115.intra-system.co.jp:1508 (0.000s)(1) 01/24 11:55:53.06 [3860] 52+20: Proxy: host=v99he115.intra-system.co.jp; User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_12; DIRECT 01/24 11:55:53.06 [3860] 52+20: HCKA:[0] keep-alive; host=v99he115.intra-system.co.jp; (User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_12) 01/24 11:55:53.08 [3860] 52+20: REQUEST - GET http://vdsvawv1:30080/lib/CParts.jar HTTP/1.1^M 01/24 11:55:53.08 [3860] 52+20: HOSTS[5] cache can't be overwritten: vdsvawv1->vdsvawv1.intra-system.co.jp 01/24 11:55:53.09 [3860] 52+20: PATH> http://vdsvawv1:30080!v99say98.intra-system.co.jp:8443!v99he115.intra-system.co.jp:1508!anonymous@v99he115.intra-system.co.jp;1201143353 01/24 11:55:53.09 [3860] 52+20: REQUEST = (no-cache)[http://vdsvawv1:30080/] GET /lib/CParts.jar HTTP/1.1^M 01/24 11:55:53.09 [3860] 52+20: connectTO: assume in non-blocking mode 01/24 11:55:53.11 [3860] 52+20: ConnectToServer connected [30] {10.9.44.50:30080 <- 10.252.101.52:1563} [0.016s] 01/24 11:55:53.11 [3860] 52+20: willSTLS_SV: ServerFlags=10 01/24 11:55:53.11 [3860] 52+20: HTTP => (vdsvawv1:30080) GET /lib/CParts.jar HTTP/1.1^M 01/24 11:55:53.15 [3860] 52+20: #HT11 NO-response-buffering: chunked mode 01/24 11:55:53.15 [3860] 52+20: #HT11 chunked, should skip: Content-Length: 668684^M 01/24 11:55:53.15 [3860] 52+20: #HT11 SERVER ver[HTTP/1.1] conn[] 01/24 11:55:53.15 [3860] 52+20: #HT11 server KEEP-ALIVE 01/24 11:55:53.15 [3860] 52+20: #HT11 --putChunk-Header: Transfer-Encoding: chunked^M 01/24 11:55:53.15 [3860] 52+20: HTTP/1.1 200 Content-{Type:text/plain Encoding:[/] Leng:668684} Server:Hitachi Web Server 01/24 11:55:53.15 [3860] 52+20: non-text in text type1 resp.(0/7)90 [vdsvawv1]/lib/CParts.jar 【クライアントキャッシュに有る場合のDeleGateログ】 01/24 12:01:15.52 [3624] 55+16: (1) accepted [58] -@[10.9.16.86]v99he115.intra-system.co.jp:1616 (0.016s)(1) 01/24 12:01:15.52 [3624] 55+16: = (1198099178) If-Modified-Since: Wed, 19 Dec 2007 21:19:38 GMT^M 01/24 12:01:15.52 [3624] 55+16: Proxy: host=v99he115.intra-system.co.jp; User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_12; DIRECT 01/24 12:01:15.52 [3624] 55+16: HCKA:[0] keep-alive; host=v99he115.intra-system.co.jp; (User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_12) 01/24 12:01:15.53 [3624] 55+16: REQUEST - GET http://vdsvawv1:30080/lib/CParts.jar HTTP/1.1^M 01/24 12:01:15.60 [3624] 55+16: PATH> http://vdsvawv1:30080!v99say98.intra-system.co.jp:8443!v99he115.intra-system.co.jp:1616!anonymous@v99he115.intra-system.co.jp;1201143675 01/24 12:01:15.60 [3624] 55+16: REQUEST = (no-cache)[http://vdsvawv1:30080/] GET /lib/CParts.jar HTTP/1.1^M 01/24 12:01:15.60 [3624] 55+16: connectTO: assume in non-blocking mode 01/24 12:01:15.61 [3624] 55+16: ConnectToServer connected [30] {10.9.44.50:30080 <- 10.252.101.52:1656} [0.015s] 01/24 12:01:15.61 [3624] 55+16: willSTLS_SV: ServerFlags=10 01/24 12:01:15.61 [3624] 55+16: HTTP => (vdsvawv1:30080) GET /lib/CParts.jar HTTP/1.1^M 01/24 12:01:15.63 [3624] 55+16: HTTP status: 304 Not Modified => 66b000/1 01/24 12:01:15.63 [3624] 55+16: #HT11 NO-response-buffering: chunked mode 01/24 12:01:15.63 [3624] 55+16: #HT11 SERVER ver[HTTP/1.1] conn[] 01/24 12:01:15.63 [3624] 55+16: #HT11 server KEEP-ALIVE 01/24 12:01:15.64 [3624] 55+16: HTTP/1.1 304 Content-{Type: Encoding:[/] Leng:0} Server:Hitachi Web Server 01/24 12:01:15.64 [3624] 55+16: #HT11 NO-BODY: remsize=16384 01/24 12:01:15.64 [3624] 55+16: HTTP transmitted: 94head+0/0body=>0txt+0bin->0/0, 3i/1o/0f/0.0 --c-- 01/24 12:01:15.64 [3624] 55+16: #HT11 close svsokcs[31,32] 01/24 12:01:15.66 [3624] 55+16: unlink empty cache: F:\CACHE/http/vdsvawv1..30080/lib/CParts.jar#LOADING 01/24 12:01:15.66 [3624] 55+16: HCKA:[0] closed -- H:HTTPCONF=bugs:no-keepalive 【クライアントキャッシュに無い場合のクライアントからのリクエスト】 ※上記のログと同じタイミングで取ったものではありません。 GET http://vdsvbw01:30080/lib/CParts.jar HTTP/1.1 accept-encoding: pack200-gzip,gzip content-type: application/x-java-archive Cache-Control: no-cache Pragma: no-cache User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_12 Host: vdsvbw01:30080 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Proxy-Connection: keep-alive 【クライアントキャッシュに有る場合のクライアントからのリクエスト】 ※上記のログと同じタイミングで取ったものではありません。 GET http://vdsvbw01:30080/lib/CParts.jar HTTP/1.1 accept-encoding: pack200-gzip,gzip content-type: application/x-java-archive Cache-Control: no-cache Pragma: no-cache User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_12 Host: vdsvbw01:30080 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Proxy-Connection: keep-alive If-Modified-Since: Wed, 19 Dec 2007 21:19:38 GMT また、本件調査にあたり、メーリングリストを調べた所、少し気になる記事がありました。 すごく古い記事ですが・・ 以下、引用します(Article delegate/6314 (98Jan30) Re: HTTP Proxy : not transmit cache data より) ************************************************ |(9) DeleGate は test.html のキャッシュ有効期限をチェックし、 | 有効期限切れなので、(8) で Client-A が付けてきたものではなく | HTTP Cache にある test.html を元にした If-Modified-Since に | 付けなおして、Target-A に対して test.html の GET 要求を出す。 正確には、 「クライアントのキャッシュが、DeleGateのキャッシュより古いなら」つまり、 クライアントから送られて来た If-Modified-Since の値(たぶん、 クライアントがキャッシュしているデータの日付=Last-Modified)が、 DeleGateがキャッシュしているデータの日付=Last-Modified より古いなら、 サーバに送る If-Modified-Since を付け直す、になっているようです。 つまり、クライアントがDeleGateより新しいデータをキャッシュしているなら、 DeleGateのキャッシュを無視して要求を通し、変更無し応答304ならそのまま 304を通す。この状況は、複数のproxyや直接接続を併用している場合に起こり 得ます。どういう意図だったかいまいち思い出せませんが、おそらく、、、 そのクライアントしか要求しない可能性の高いデータを取り寄せる無駄を 減らし、またそのクライアントの応答時間を無用に長くするというとばっちり 防ぐ、というようなことだったかと思います。たしか、RINGER を運用していて そのような無駄な転送が多かったので、こうしたような記憶が。。。 |(10) Target-A からは、「test.html は更新されていない」という | 応答コード 304 (Not Modiifed) のヘッダだけが転送される。 | |(11) 上記 (10) で転送されてきた応答コード 304 が、そのまま Client-A に | 転送される。 | | → DeleGate の HTTP Cache にある、最新の test.html が Client-A に | 転送されない。 |ということで、(9) のところで DeleGate が If-Modified-Since を |付けなおしているにもかかわらず、その応答をそのまま Client-A に渡すので |このような現象が発生するようです。修正していただけましたら幸いです。 同封のようなのでどうでしょうね? (11) 「クライアントのキャッシュが、DeleGateのキャッシュよりが新しいなら」 304 をそのままクライアントに転送する。そうでないなら、実体を返す。 ************************************************ 引用終わり 上記記事の(9)ならびに(11)の対応について、(当時(11)は個別にパッチ提供されたようですが、)現状のバージョンには 反映されていますでしょうか? (リリースノートを追っかけきれなかったため、明日実機確認しますが) ご教示お願い致します。 此方の調査、情報収集が不十分なままで誠に恐縮ですが。是非ともご一報頂けますよう、お願い致します。