Scrapy はリダイレクトを追跡する前に表示できる
プロキシ経由の GET の初期リダイレクト ステータスと Location をリクエスト メタデータ経由で一時的に公開し、リダイレクト処理を HTTP エラー フィルタリングから分離したままにする。
プロキシ経由の GET はサーバーに到達した後、最終的な失敗が最初の応答を覆い隠すまでリダイレクトを追跡する場合があります。その最初の応答を診断のために公開します:
request = scrapy.Request(
'https://service.example/page',
callback=inspect_redirect,
meta={
'proxy': 'http://proxy.example:8080',
'dont_redirect': True,
'handle_httpstatus_list': [301, 302, 303, 307, 308],
},
)
このリクエストはスパイダーの既存の start または callback フローでスケジュールします。許可された公開ページの検査では、HTTP プロキシ リスト がリクエストのプロキシ URL の候補を提供します。inspect_redirect は応答ステータスと Location ヘッダーを記録し、再び盲目的に追跡しないようにします。
dont_redirect はこのリクエストの自動リダイレクトを停止します。handle_httpstatus_list は指定したステータスを HTTP エラー フィルタリングで拒否せず callback に到達させます。これらの設定はミドルウェアの異なる責務に対応します。
リダイレクトが何を選択したかを確認します。意図した正規 URL、別のスキームやホスト名、ログイン ページ、または繰り返しのサイクルです。正常な転送後に受け取った 302 は、プロキシ接続を開けなかった場合とは異なる観察です。
通常のリダイレクト処理が復元されると、Scrapy は応答のリクエスト メタデータに redirect_urls と redirect_reasons を公開します。これらはクロール全体でリダイレクトを無効のままにせず、最終結果に至る経路を保持できます。
最終的な応答は、アプリケーションが意図したページであるとは限りません。宛先と応答内容をルーティングの診断とともに保持してください。