FessのWebクロールで、robots.txtの判定、クロール間隔、過負荷時の再試行、変更のないページの再取得を見直しました。クロール先のルールを適切に扱い、再クロール時の無駄な転送も減らすための変更です。
robots.txtのルール判定
robots.txtをオリジン単位で解決し、AllowとDisallowの最長一致を使って判定します。同じ長さならAllowを優先します。以前のようにAllowをクロール全体のURL許可パターンへ変換する方式をやめ、開始URLにもルールを適用します。
HTTPクライアントとPlaywrightクライアントで共通の判定処理を使うようにしました。ルールで禁止されたURLはINFOログに残し、アクセス失敗URLには登録しません。
robots.txtを取得できない場合
404などの4xxは許可として扱いますが、429、5xx、タイムアウトなどの場合は待機と再試行を行います。標準では最初の失敗後に3回まで再試行し、それでも取得できなければ、そのクロール中は対象オリジンへのアクセスを停止します。
従来の「robots.txtを取得できなければ許可する」挙動から変わる点です。従来の扱いが必要なクロール設定では、パラメーター欄に以下を指定できます。
client.robotsTxtAllowOnUnavailable=trueこれはrobots.txtのルールそのものを無効にする設定ではありません。取得失敗も障害として追えるように、後続の修正でアクセス例外を報告し、同じURLの重複報告を抑えています。ルールによる禁止と通信障害を区別して確認できます。
間隔とバックオフ
robots.txtのCrawl-delayをオリジンごとに適用します。小数の値にも対応し、標準の待機上限は60秒です。増分クロールで同じURLに対して行うHEADとGETの間隔を個別に空ける仕組みではなく、URL単位でペースを調整します。
429や503の応答ではRetry-Afterを使い、ない場合は指数的に待機時間を増やして再試行します。既存のクロール設定の間隔と組み合わせて利用できます。
条件付きGETで再転送を減らす
増分クロールでは従来のHEADとLast-Modifiedの比較を残し、それだけで変更を判断できない場合に、保存したETagや更新日時をGETの条件へ渡します。
If-None-Match: <保存済みのETag>
If-Modified-Since: <保存済みの更新日時>304 Not Modifiedなら本文を再取得・再解析せず、保存済みアンカーを使って後続URLを処理し、有効期限を延長します。対象はHTTP・HTTPSで、ファイル、SMB、FTPやPlaywrightの条件付きGETには適用しません。
クロール設定変更後などに本文を必ず取り直したい場合は、増分クロールを無効にして再取得してください。アップグレード後は、取得できないrobots.txtが原因で停止していないかログを確認するとよいと思います。