さとみかんに捕捉されているページの制作者様で、なんだか更新日時が正しく反映されてないゾ!という場合がありましたら、このページを参考にしてみてください。
なつみかんは、だいたい次のような動作原理でチェック対象ページの更新日時を調べます。
更新日時がなんだか正常に取得されていないと感じた場合は、以下の手順を試してみてください。
XBitHack full
と書いて、アンテナから捕捉されてるファイルに実行権限を付ければ、うまくいくかもしれません。2002/04/05 16:40
" とか "Fri, 05 Apr 2002 16:14:02 JST
" とかで OK 。なつみかんはアタマがいいから。もしだめなら、日時を書いておく位置を変えるとか、日時書式をいろいろ変えてみる方向で。 WWWC 用 META タグやちえりリスト用の META タグがあれば話は早いです。よくわからなければ、メール等さまざまな方法でご相談ください。
「さとみかん」は、捕捉先の URI が別 URI へのリダイレクトになっている場合も、そのリダイレクトを追跡して更新日時を問題なく取得できます。ただし、以下のようなケースではリダイレクトを追跡しないので、更新日時を正常取得できません。
HTTP 応答ヘッダの Location フィールドの値は、必ず「絶対 URI (absolute URI) をひとつだけ」でないとダメです。相対パスで示されている場合は無視します(リダイレクトを追跡しません)。
「さとみかん」は、ステータス 301 のリダイレクトを追跡しません。ステータス 302 のリダイレクトのみを追跡します。
ステータス 301 は、元の URI にあったリソースがリダイレクト先 URI へ恒久的に移動したことを示します。時の流れあるいはログの蓄積に従って最新記事ページ(実体)の URI が次々変わってゆくなかで、「最新記事ページの URI 」を擬似的に固定するためにリダイレクトを使っている場合(その例)、その用途に相応しいステータスコードは 302 です。
リクエストされたリソースは新しい恒久的な URI に割り当てられたので、以降そのリソースへの参照は返された URI の一つを使用すべきである。リンク編集機能を持つクライアントは、可能であればサーバにより返された新しい参照の一つ以上の Request-URI を参照するように自動的に再リンクすべきである。
リクエストされたリソースは、一時的に別の URI に属している。このリダイレクションは場合によって変更されるかもしれないので、クライアントは将来のリクエストではその Request-URI を使い続けるべきである。
「さとみかん」は、HTML ソースに書き込まれた <meta http-equiv="refresh" content="...">
を解釈しません。