In message <_A85@delegate-ja.ML_> on 01/25/08(00:04:25)
you <pkuaabrv6-jmfhzl4ayqdw.ml@delegate.org> wrote:
 |日立システムの松本と申します。
...
 |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にキャッシュされていれば、キャッシュ中のLast-Modifiedに基づいて、
あるいはキャッシュファイルの日付から、DeleGateがIf-Modified-Sinceを生成
して要求し、変更無しであればサーバから304応答を得て、クライアントに200応答
を返すでしょう。
そのような場合("-vd"オプションつきでの)ログには、"HTTP <=+= 304 [cache-path]"
というようなメッセージが残されます。


 |【調査状況】
 |DeleGateがクライアントからIf-Modified-Sinceの無いGETリクエストを受けた場合、DeleGateが目的のWebサーバに対してもIf-Modified-Sinceを付けず
 |にリクエストしている様に思えます（DeleGate〜Webサーバ間のキャプチャが取れなかったため創造の域です。すみません）が、
 |どうも当現象となるのがJAVAの場合のみの様にも見受けられるのです。（HTML、画像、Curlなどでは起きていない様に見えるのですがまだザクッと見た
 |だけですのではっきりしたことは判りません。継続して切り分け中です）
 |JAVAはブラウザ（IE6)のキャッシュではなく、独自のキャッシュを使用していますが、DeleGate側から見ればクライアント内でどこのキャッシュが使われて
 |いるかなどは関係なく、受けたリクエスト内のヘッダで振る舞いが決まるものと思っていますので、単にJAVAコンテンツへのリクエストの出し方が悪いだけ
 |なのか、（初心者で申しわけありません）それともDeleGateのそもそもの仕様なのかについて、まずは切り分けを頂ければ有り難く思います。


以下のログで、"REQUEST= (no-cache)" とあるのは、このリクエストがクライアント
によってリロードされたことを示しています。その場合にはDeleGateは、手元の
キャッシュの有無や日付に関係なく、サーバからの最新のデータを取得しようと
します。そのため、サーバへのリクエストに If-Modified-Sinceは付加しません
(conditional request にしません)。

この場合、クライアントが送ってきているリクエストのヘッダに、"Pragma: no-cache"
や "Cache-Control: no-cache" があるなら、DeleGateのこの動作はそうあるべき
ものだと思います。ただ、もし "Cache-Control: max-age=0" によるリロードである
場合には、If-Modified-Since を使用して新鮮さを検査するようにするほうが、
良いかも知れません。(RFC2616 14.9.4)


 |【クライアントキャッシュに無い場合の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
 |

この後のログが重要ですが、キャッシュに書き込まれた場合には、
"XXX bytes written to [path]" というようなログがあるでしょう。あるいは、
受信データのサイズ不一致か何かの理由でキャッシュしなかった場合には、
その理由コードが示されているはずです。
例えば、サーバが応答に、"Last-Modified"を指示していないとか、Set-Cookie
を含んでいるとか、サイズが不一致だとか、リクエストにCookieを含んでいる
とか、などなどです。

またこのログでは、クライアントからのリクエストのホスト名がFQDNでなされてい
ないこと、サーバからのレスポンスのContent-Typeが、バイナリデータであるのに
text/plain になっていることが示されています。これらがキャッシュの読み書き
に何か影響している可能性はあります。

DeleGateに "-vd" オプションをつけて実行すれば、キャッシュの読み書き等に
関する、より詳しい情報が得られますので、ヒントになると思います。
また、FFROMCL=-tee-n-h FTOSV=-tee-n-h FFROMSV=-tee-n-h などのオプションを
つければ、クライアントやサーバとやりとりされるリクエストやレスポンスの
ヘッダを覗くことができます。

　　　　　　　 　　　        9 9　　
┌─┐┬┌──┬┐ ／／\^^ ( e ); {Do the more with the less -- B. Fuller}
├─┤│└─┐│ ／　877m\_<   >_ <URL:http://www.delegate.org/delegate/>
┴　└┴──┘┴──────────────────────────────
佐藤豊＠情報技術研究部門.産業技術総合研究所(独立行政法人)