ダウンローダー・ミドルウェア¶

ダウンローダー・ミドルウェアは、Scrapyのリクエスト/レスポンス処理へのフックのフレームワークです。Scrapyのリクエストとレスポンスをグローバルに変更するための軽量で低レベルのシステムです。

ダウンローダーミドルウェアをアクティブにする¶

ダウンローダー・ミドルウェア・コンポーネントを有効にするには、それを DOWNLOADER_MIDDLEWARES 設定に追加します。これは、キーがミドルウェア・クラス・パスであり、値がミドルウェアの順序である辞書です。

ここに例があります:

DOWNLOADER_MIDDLEWARES = {
    'myproject.middlewares.CustomDownloaderMiddleware': 543,
}

DOWNLOADER_MIDDLEWARES 設定は、Scrapyで定義された DOWNLOADER_MIDDLEWARES_BASE 設定とマージされ(オーバーライドされることはありません)、有効なミドルウェアの最終ソートリストを取得するために順序でソートされます。1つはエンジンに近く、最後はダウンローダーに近いものです。つまり、各ミドルウェアの process_request() メソッドは、ミドルウェアの昇順(100、200、300…)で呼び出され、各ミドルウェアの process_response() メソッドは、降順で呼び出されます。

ミドルウェアに割り当てる順序を決定するには、 DOWNLOADER_MIDDLEWARES_BASE 設定を参照し、ミドルウェアを挿入する場所に応じて値を選択します。各ミドルウェアは異なるアクションを実行し、ミドルウェアは適用される以前の(または後続の)ミドルウェアに依存する可能性があるため、順序は重要です。

組み込みのミドルウェア( DOWNLOADER_MIDDLEWARES_BASE で定義され、デフォルトで有効になっているミドルウェア)を無効にするには、プロジェクトの DOWNLOADER_MIDDLEWARES 設定で定義し、その値として None を割り当てる必要があります。たとえば、ユーザーエージェントミドルウェアを無効にする場合、以下の通りです:

DOWNLOADER_MIDDLEWARES = {
    'myproject.middlewares.CustomDownloaderMiddleware': 543,
    'scrapy.downloadermiddlewares.useragent.UserAgentMiddleware': None,
}

最後に、特定の設定で一部のミドルウェアを有効にする必要がある場合があることに注意してください。詳細については、各ミドルウェアのドキュメントを参照してください。

あなた自身のダウンローダー・ミドルウェアを書く¶

各ダウンローダー・ミドルウェアは、以下で定義される1つ以上のメソッドを定義するPythonクラスです。

メインのエントリー・ポイントは from_crawler クラス・メソッドで、これは Crawler インスタンスを受け取ります。 Crawler オブジェクトは、たとえば設定へのアクセスを提供します。

class scrapy.downloadermiddlewares.DownloaderMiddleware¶

注釈

どのダウンローダー・ミドルウェア・メソッドも遅延オブジェクト(deferred)を返す場合があります。

process_request(request, spider)¶

このメソッドは、ダウンロード・ミドルウェアを通過するリクエストごとに呼び出されます。

process_request() の結果は次のいずれかでなければなりません: None を返す、 Response オブジェクトを返す、 Request オブジェクトを返す、 IgnoreRequest 例外を起こす。

None を返した場合、Scrapyはこのリクエストの処理を続け、最終的に適切なダウンローダー・ハンドラーが実行されたリクエスト(およびダウンロードされたレスポンス）が呼ばれるまで、他のすべてのミドルウェアを実行します。

Response オブジェクトを返す場合、Scrapyは他の 任意の process_request() メソッドまたは process_exception() メソッド、または適切なダウンロード関数の呼び出しを考慮しません。そのレスポンスオブジェクトそのものを返します。なお、インストールされたミドルウェアの process_response() メソッドは、すべてのレスポンスで常に呼び出されます。

Request オブジェクトを返す場合、Scrapyはprocess_requestメソッドの呼び出しを停止し、返されたリクエストを再スケジュールします。新しく返されたリクエストが実行されると、ダウンロードされたレスポンスで適切なミドルウェア・チェーンが呼び出されます。

IgnoreRequest 例外が発生した場合、インストールされたダウンローダー・ミドルウェアの process_exception() メソッドが呼び出されます。それらのいずれもが例外を処理しない場合、リクエストのerrback関数( Request.errback )が呼び出されます。発生した例外を処理するコードがない場合、無視され、(他の例外とは異なり)ログに記録されません。

パラメータ

request (Request object) -- 処理中のリクエスト
spider (Spider object) -- このリクエストの対象となるスパイダー

process_response(request, response, spider)¶

process_response() は次のいずれかの結果でなければなりません: Response オブジェクトを返す、 Request オブジェクトを返す、 IgnoreRequest 例外を起こす。

Response が返された場合(指定されたレスポンスと同じか、まったく新しいレスポンスである可能性があります)、そのレスポンスは次のチェーン内のミドルウェアの process_response() で引き続き処理されます。

Request オブジェクトを返す場合、ミドルウェア・チェーンは停止し、返されたリクエストは将来ダウンロードされるように再スケジュールされます。これは、リクエストが process_request() から返される場合と同じ動作です。

IgnoreRequest 例外が発生した場合、リクエストのerrback関数( Request.errback )が呼び出されます。発生した例外を処理するコードがない場合、無視され、(他の例外とは異なり)ログに記録されません。

パラメータ

request (is a Request object) -- レスポンスを引き起こしたリクエスト
response (Response object) -- 処理中のレスポンス
spider (Spider object) -- このレスポンスを意図したスパイダー

process_exception(request, exception, spider)¶

Scrapyは、ダウンロード・ハンドラーまたは、(ダウンローダー・ミドルウェアから) process_request() が例外( IgnoreRequest 例外を含む）を発生させると、 process_exception() を呼び出します

process_exception() は、 None または Response オブジェクトまたは Request オブジェクトを返す必要があります。

None を返す場合、Scrapyはこの例外の処理を続け、ミドルウェアが無くなりデフォルトの例外処理が開始されるまで、順にインストールされた他のミドルウェアの process_exception() メソッドを実行します。

Response オブジェクトを返す場合、インストールされたミドルウェアの process_response() メソッド・チェーンが開始され、Scrapyは他のミドルウェアの process_exception() メソッドを呼び出すことはありません。

Request オブジェクトを返す場合、返されたリクエストは将来ダウンロードされるように再スケジュールされます。これは、レスポンスを返すのと同様に、ミドルウェアの process_exception() メソッドの実行を停止します。

パラメータ

request (is a Request object) -- 例外を生成したリクエスト
exception (an Exception object) -- 発生した例外
spider (Spider object) -- このリクエストの対象となるスパイダー

from_crawler(cls, crawler)¶

存在する場合、このクラス・メソッドは Crawler からミドルウェア・インスタンスを作成するために呼び出されます。ミドルウェアの新しいインスタンスを返す必要があります。クローラー・オブジェクトは、設定や信号などのすべてのScrapyコアコンポーネントへのアクセスを提供します。それはミドルウェアがそれらにアクセスし、その機能をScrapyにフックする方法です。

パラメータ: crawler (Crawler object) -- このミドルウェアを使用するクローラー

組み込みダウンローダー・ミドルウェア・リファレンス¶

この文書では、Scrapyに付属するすべてのダウンローダー・ミドルウェア・コンポーネントについて説明します。それらの使用方法と独自のダウンローダ・ミドルウェアの作成方法については、ダウンローダミドルウェア使用ガイドを参照してください。

デフォルトで有効になっているコンポーネント(およびその順序)のリストについては、 DOWNLOADER_MIDDLEWARES_BASE 設定を参照してください。

CookiesMiddleware¶

class scrapy.downloadermiddlewares.cookies.CookiesMiddleware¶: このミドルウェアにより、セッションを使用するサイトなど、クッキーを必要とするサイトを操作できます。Webサーバーが送信したクッキーを追跡し、Webブラウザーが行うように、その後の(スパイダーからの)リクエストでそれらを送り返します。

次の設定を使用して、クッキー・ミドルウェアを構成(configure)できます:

COOKIES_ENABLED
COOKIES_DEBUG

COOKIES_ENABLED¶

デフォルト: True

クッキー・ミドルウェアを有効にするかどうか。無効にすると、クッキーはWebサーバーに送信されません。

Request.meta['dont_merge_cookies'] が True と評価される場合、 COOKIES_ENABLED 設定にかかわらず、リクエス・トクッキーは Webサーバーに 送信されません 。そして Response で受信されたクッキーは、既存のクッキーとは マージされません 。

詳細については、 Request の cookies パラメーターを参照してください。

COOKIES_DEBUG¶

デフォルト: False

有効にすると、Scrapyはリクエストで送信されたすべてのクッキー( Cookie ヘッダー)およびレスポンスで受信されたすべてのクッキー( Set-Cookie ヘッダー)をログに記録します。

COOKIES_DEBUG が有効になっているログの例を次に示します:

2011-04-06 14:35:10-0300 [scrapy.core.engine] INFO: Spider opened
2011-04-06 14:35:10-0300 [scrapy.downloadermiddlewares.cookies] DEBUG: Sending cookies to: <GET http://www.diningcity.com/netherlands/index.html>
        Cookie: clientlanguage_nl=en_EN
2011-04-06 14:35:14-0300 [scrapy.downloadermiddlewares.cookies] DEBUG: Received cookies from: <200 http://www.diningcity.com/netherlands/index.html>
        Set-Cookie: JSESSIONID=B~FA4DC0C496C8762AE4F1A620EAB34F38; Path=/
        Set-Cookie: ip_isocode=US
        Set-Cookie: clientlanguage_nl=en_EN; Expires=Thu, 07-Apr-2011 21:21:34 GMT; Path=/
2011-04-06 14:49:50-0300 [scrapy.core.engine] DEBUG: Crawled (200) <GET http://www.diningcity.com/netherlands/index.html> (referer: None)
[...]

DefaultHeadersMiddleware¶

class scrapy.downloadermiddlewares.defaultheaders.DefaultHeadersMiddleware¶: このミドルウェアは、 DEFAULT_REQUEST_HEADERS 設定で指定されたすべてのデフォルト・リクエスト・ヘッダーを設定します。

DownloadTimeoutMiddleware¶

class scrapy.downloadermiddlewares.downloadtimeout.DownloadTimeoutMiddleware¶: このミドルウェアは、 DOWNLOAD_TIMEOUT 設定または download_timeout スパイダー属性で指定されたリクエストのダウンロード・タイムアウトを設定します。

注釈

download_timeout リクエスト・メタ・キーを使用して、リクエストごとにダウンロード・タイムアウトを設定することもできます。これは、DownloadTimeoutMiddlewareが無効になっている場合でもサポートされます。

HttpAuthMiddleware¶

class scrapy.downloadermiddlewares.httpauth.HttpAuthMiddleware¶

このミドルウェアは、 Basic access authentication (別名BASIC認証)を使用して、特定のスパイダーから生成されたすべてのリクエストを認証します。

特定のスパイダーからのBASIC認証を有効にするには、それらのスパイダーの http_user と http_pass 属性を設定します。

例:

from scrapy.spiders import CrawlSpider

class SomeIntranetSiteSpider(CrawlSpider):

    http_user = 'someuser'
    http_pass = 'somepass'
    name = 'intranet.example.com'

    # .. rest of the spider code omitted ...

HttpCacheMiddleware¶

class scrapy.downloadermiddlewares.httpcache.HttpCacheMiddleware¶

このミドルウェアは、すべてのHTTPリクエストおよびレスポンスに低レベルのキャッシュを提供します。キャッシュ・ストレージ・バックエンドおよびキャッシュ・ポリシーと組み合わせる必要があります。

Scrapyには3つのHTTPキャッシュ・ストレージ・バックエンドが付属しています:

ファイルシステム・ストレージ・バックエンド(デフォルト)

DBMストレージ・バックエンド

LevelDBストレージ・バックエンド

HTTPCACHE_STORAGE 設定でHTTPキャッシュ・ストレージ・バックエンドを変更できます。また、独自のストレージ・バックエンドの実装もできます。

Scrapyには2つのHTTPキャッシュ・ポリシーが付属しています:

RFC2616ポリシー

ダミー・ポリシー(デフォルト)

HTTPCACHE_POLICY 設定でHTTPキャッシュ・ポリシーを変更できます。または、独自のポリシーを実装することもできます。

dont_cache メタ・キーが True に等しいことを使用して、すべてのポリシーで応答をキャッシュしないようにすることもできます。

ダミー・ポリシー(デフォルト)¶

class scrapy.extensions.httpcache.DummyPolicy¶

このポリシーは、HTTPキャッシュ制御ディレクティブを認識しません。すべてのリクエストとそれに対応するレスポンスはキャッシュされます。同じリクエストが再び現れるると、インターネットから何も転送せずにレスポンスが返されます。

ダミー・ポリシーは、スパイダーをより高速にテストする(毎回ダウンロードを待つ必要なしに)ときや、インターネット接続が利用できないときにスパイダーをオフラインで試すのに役立ちます。設計目標は、スパイダーの実行を前に実行したとおりに再現できるようにすることです。

RFC2616ポリシー¶

class scrapy.extensions.httpcache.RFC2616Policy¶

このポリシーは、RFC2616準拠のHTTPキャッシュ、つまりHTTP Cache-Control認識を提供します。これは、新たな生成物に狙いを定め、変更されていないデータのダウンロードを回避するために連続実行で使用されます(帯域幅を節約し、クロールを高速化するため)。

実装されているもの:

no-store キャッシュ制御ディレクティブが設定されている場合、レスポンス/リクエストを保存しようとしないでください。
no-cache キャッシュ制御ディレクティブが新しいレスポンスに対しても設定されている場合、キャッシュからレスポンスを提供しません
max-age キャッシュ制御ディレクティブから鮮度寿命を計算します
Expires レスポンス・ヘッダーから鮮度寿命を計算します
Last-Modified レスポンス・ヘッダーから鮮度の有効期間を計算します(Firefoxで使用されるヒューリスティック)
Age レスポンス・ヘッダーから現在の年齢を計算する
Date ヘッダーから現在の年齢を計算
Last-Modified レスポンス・ヘッダーに基づいて古いレスポンスを再検証します
ETag レスポンス・ヘッダーに基づいて古いレスポンスを再検証します
受信したレスポンスがない場合に Date ヘッダーを設定します
リクエストで max-stale キャッシュ制御ディレクティブをサポート

これにより、スパイダーを完全なRFC2616キャッシュ・ポリシーで構成できますが、HTTP仕様に準拠したまま、リクエストごとの再検証を回避できます。

例:

Cache-Control: max-stale=600 をリクエスト・ヘッダーに追加して、600秒以内ならば有効期限を超えたレスポンスを受け入れます。

RFC2616, 14.9.3 も参照下さい。

実装されてないもの:

Pragma: no-cache サポート https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
Vary ヘッダー・サポート https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6
更新または削除後の無効化 https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10
…その他いろいろ…

ファイルシステム・ストレージ・バックエンド(デフォルト)¶

class scrapy.extensions.httpcache.FilesystemCacheStorage¶

ファイルシステム・ストレージ・バックエンドは、HTTPキャッシュ・ミドルウェアで使用できます。

各リクエスト/レスポンスのペアは、次のファイルを含む異なるディレクトリに保存されます:

request_body - 生のリクエスト・ボディそのもの
request_headers - リクエスト・ヘッダ(生HTTP書式)
response_body - 生のレスポンス・ボディそのもの
response_headers - リクエスト・ヘッダ(生HTTP書式)
meta - Python repr() 形式の、このキャッシュ・リソースのメタ・データ(grepに優しい形式)
pickled_meta - `` meta`` と同じメタデータですが、より効率的な逆シリアル化のために直列化(pickled)されています

ディレクトリ名はリクエストのフィンガー・プリントから作成され( scrapy.utils.request.fingerprint 参照)、1つのレベルのサブ・ディレクトリを使用して、同じディレクトリに多くのファイルを作成しないようにします(多くのファイルシステムでは非効率的です)。ディレクトリの例以下です:

/path/to/cache/dir/example.com/72/72811f648e718090f041317756c03adb0ada46c7

DBMストレージ・バックエンド¶

class scrapy.extensions.httpcache.DbmCacheStorage¶

バージョン 0.13 で追加.

DBM ストレージ・バックエンドは、HTTPキャッシュ・ミドルウェアでも使用できます。

デフォルトでは、anydbm モジュールを使用しますが、 HTTPCACHE_DBM_MODULE 設定で変更できます。

LevelDBストレージ・バックエンド¶

class scrapy.extensions.httpcache.LeveldbCacheStorage¶

バージョン 0.23 で追加.

LevelDB ストレージ・バックエンドは、HTTPキャッシュ・ミドルウェアでも使用できます。

LevelDBデータベースに同時にアクセスできるプロセスは1つだけなので、このバックエンドは開発にはお勧めできません。そのため、同じスパイダーに対してクロールを実行してScrapyシェルを並行して開くことはできません。

このストレージ・バックエンドを使用するには、 LevelDB python bindings をインストールします(例: pip install leveldb )。

あなた自身のストレージ・バックエンドを書く¶

以下に説明するメソッドを定義するPythonクラスを作成することにより、キャッシュス・トレージ・バックエンドを実装できます。

class scrapy.extensions.httpcache.CacheStorage¶

open_spider(spider)¶

このメソッドは、クロールのためにスパイダーがオープンされた後に呼び出されます。 open_spider シグナルを処理します。

パラメータ: spider (Spider object) -- オープンされたスパイダー

close_spider(spider)¶

このメソッドは、スパイダーがクローズさられた後に呼び出されます。 close_spider シグナルを処理します。

パラメータ: spider (Spider object) -- クローズされたスパイダー

retrieve_response(spider, request)¶

キャッシュに存在する場合はレスポンスを返し、そうでない場合は None を返します。

パラメータ

spider (Spider object) -- リクエストを生成したスパイダー
request (Request object) -- キャッシュされたレスポンスを見つけるためのリクエスト

store_response(spider, request, response)¶

与えられたレスポンスをキャッシュに保存します。

パラメータ

spider (Spider object) -- このレスポンスを意図したスパイダー
request (Request object) -- スパイダーが生成した対応するリクエスト
response (Response object) -- キャッシュに保存するレスポンス

ストレージ・バックエンドを使用するには、以下の設定をします:

HTTPCACHE_STORAGE をあなたのカスタム・ストレージ・クラスのPythonインポート・パスに設定します。

HTTPCache middleware 設定¶

HttpCacheMiddleware は次の設定で構成(configure)できます:

HTTPCACHE_ENABLED¶

バージョン 0.11 で追加.

デフォルト: False

HTTPキャッシュを有効にするかどうか。

バージョン 0.11 で変更: バージョン0.11より前は、 HTTPCACHE_DIR がキャッシュを有効にするのに使われていました。

HTTPCACHE_EXPIRATION_SECS¶

デフォルト: 0

キャッシュされたリクエストの有効期限(秒単位)。

この時間より古いキャッシュされたリクエストは再ダウンロードされます。ゼロの場合、キャッシュされたリクエストは期限切れになりません。

バージョン 0.11 で変更: バージョン0.11より前は、ゼロは、キャッシュされたリクエストが常に期限切れになることを意味しました。

HTTPCACHE_DIR¶

デフォルト: 'httpcache'

(低レベル)HTTPキャッシュを保存するために使用するディレクトリ。空の場合、HTTPキャッシュは無効になります。相対パスが指定されている場合、プロジェクト・データ・ディレクトリからの相対パスが使用されます。詳細については、 Scrapyプロジェクトのデフォルト構造を参照してください。

HTTPCACHE_IGNORE_HTTP_CODES¶

バージョン 0.10 で追加.

デフォルト: []

これらのHTTPコードでレスポンスをキャッシュしないでください。

HTTPCACHE_IGNORE_MISSING¶

デフォルト: False

有効にすると、キャッシュに見つからないリクエストはダウンロードされずに無視されます。

HTTPCACHE_IGNORE_SCHEMES¶

バージョン 0.10 で追加.

デフォルト: ['file']

これらのURIスキームでレスポンスをキャッシュしないでください。

HTTPCACHE_STORAGE¶

デフォルト: 'scrapy.extensions.httpcache.FilesystemCacheStorage'

キャッシュ・ストレージ・バックエンドを実装するクラス。

HTTPCACHE_DBM_MODULE¶

バージョン 0.13 で追加.

デフォルト: 'anydbm'

DBMストレージ・バックエンドで使用するデータベース・モジュール。この設定は、DBMバックエンド固有です。

HTTPCACHE_POLICY¶

バージョン 0.18 で追加.

デフォルト: 'scrapy.extensions.httpcache.DummyPolicy'

キャッシュ・ポリシーを実装するクラス。

HTTPCACHE_GZIP¶

バージョン 1.0 で追加.

デフォルト: False

有効にすると、キャッシュされたすべてのデータがgzipで圧縮されます。この設定は、ファイルシステム・バックエンド固有です。

HTTPCACHE_ALWAYS_STORE¶

バージョン 1.1 で追加.

デフォルト: False

有効にすると、ページを無条件にキャッシュします。

スパイダーは、たとえば Cache-Control：max-stale で将来使用するために、すべてのレスポンスをキャッシュで利用可能にしたい場合があります。 DummyPolicyはすべてのレスポンスをキャッシュしますが、それらを再検証することはありません。また、より微妙なポリシーが望ましい場合があります。

この設定は、レスポンスの Cache-Control：no-store ディレクティブを引き続き尊重します。不要な場合は、キャッシュ・ミドルウェアにフィードするレスポンスのCache-Controlヘッダーから no-store をフィルターします。

HTTPCACHE_IGNORE_RESPONSE_CACHE_CONTROLS¶

バージョン 1.1 で追加.

デフォルト: []

無視されるレスポンスのキャッシュ制御ディレクティブのリスト。

サイトは "no-store"、"no-cache"、"must-revalidate"などを設定することがよくありますが、これらのディレクティブを尊重するとスパイダーが生成できる取引(traffic)をろうばいさせます。この設定により、クロールされるサイトにとって重要ではないことがわかっているCache-Controlディレクティブを選択的に無視できます。

スパイダーは、実際に必要な場合を除き、リクエストでCache-Controlディレクティブを発行しないため、リクエストのディレクティブはフィルタリングされません。

HttpCompressionMiddleware¶

class scrapy.downloadermiddlewares.httpcompression.HttpCompressionMiddleware¶

このミドルウェアにより、圧縮(gzip、deflate)取引(traffic)をWebサイトから送受信できます。

このミドルウェアは、 brotlipy がインストールされている場合、 brotli-compressed レスポンスのデコードもサポートします。

HttpCompressionMiddleware 設定¶

COMPRESSION_ENABLED¶

デフォルト: True

圧縮ミドルウェアを有効にするかどうか。

HttpProxyMiddleware¶

バージョン 0.8 で追加.

class scrapy.downloadermiddlewares.httpproxy.HttpProxyMiddleware¶

このミドルウェアは、 Request オブジェクトに proxy メタ値を設定することにより、リクエストに使用するHTTPプロキシを設定します。

Python標準ライブラリモジュール urllib および urllib2 と同様に、以下の環境変数に従います:

http_proxy
https_proxy
no_proxy

リクエストごとにメタ・キー proxy を http://some_proxy_server:port または http://username:password@some_proxy_server:port のような値に設定することもできます。この値は http_proxy / https_proxy 環境変数よりも優先され、また no_proxy 環境変数も無視することに注意してください。

RedirectMiddleware¶

class scrapy.downloadermiddlewares.redirect.RedirectMiddleware¶: このミドルウェアは、レスポンス・ステータスに基づいてリクエストのリダイレクトを処理します。

(リダイレクト中に)リクエストが通過するURLは Request.meta の redirect_urls キーで見つけることができます。

redirect_urls の各リダイレクトの理由は、 Request.meta の redirect_reasons キーにあります。例: [301, 302, 307, 'meta refresh']

理由の形式は、対応するリダイレクトを処理したミドルウェアによって異なります。たとえば、 RedirectMiddleware はトリガーとなったレスポンス・ステータ・スコードを整数で示しますが、 MetaRefreshMiddleware は常に 'meta refresh' 文字列を理由として使用します。

RedirectMiddleware は次の設定で設定できます(詳細については設定ドキュメントを参照してください):

Request.meta の dont_redirect キーがTrueに設定されている場合、リクエストはこのミドルウェアによって無視されます。

スパイダーでいくつかのリダイレクト・ステータス・コードを処理したい場合、これらを handle_httpstatus_list スパイダー属性で指定できます。

たとえば、リダイレクト・ミドルウェアで、301と302レスポンスを無視する(およびそれらをスパイダーに渡す)場合は、以下のようにします:

class MySpider(CrawlSpider):
    handle_httpstatus_list = [301, 302]

Request.meta の handle_httpstatus_list キーは、リクエストごとに許可するレスポンス・コードを指定するためにも使用できます。リクエストに対するレスポンス・コードを許可したい場合、メタ・キー handle_httpstatus_all を True に設定することもできます。

RedirectMiddleware 設定¶

REDIRECT_ENABLED¶

バージョン 0.13 で追加.

デフォルト: True

リダイレクト・ミドルウェアを有効にするかどうか。

REDIRECT_MAX_TIMES¶

デフォルト: 20

1回のリクエストで追跡されるリダイレクトの最大数。

MetaRefreshMiddleware¶

class scrapy.downloadermiddlewares.redirect.MetaRefreshMiddleware¶: このミドルウェアは、メタ・リフレッシュhtmlタグに基づいてリクエストのリダイレクトを処理します。

MetaRefreshMiddleware は次の設定で設定できます(詳細については設定ドキュメントを参照してください):

METAREFRESH_ENABLED
METAREFRESH_IGNORE_TAGS
METAREFRESH_MAXDELAY

このミドルウェアは、 RedirectMiddleware で説明されているように、 :REDIRECT_MAX_TIMES 設定と dont_redirect リクエスト・メタ・キーと redirect_urls リクエスト・メタ・キーと redirect_reasons リクエスト・メタ・キーに従います。

MetaRefreshMiddleware 設定¶

METAREFRESH_ENABLED¶

バージョン 0.17 で追加.

デフォルト: True

メタ・リフレッシュ・ミドルウェアを有効にするかどうか。

METAREFRESH_IGNORE_TAGS¶

デフォルト: ['script', 'noscript']

これらのタグ内のメタ・タグは無視されます。

METAREFRESH_MAXDELAY¶

デフォルト: 100

リダイレクト後の最大メタリフレッシュ遅延(秒単位)。一部のサイトでは、セッションの期限切れページへのリダイレクトにメタ・リフレッシュを使用しているため、自動リダイレクトを最大遅延に制限しています。

RetryMiddleware¶

class scrapy.downloadermiddlewares.retry.RetryMiddleware¶: 接続タイムアウトやHTTP 500エラーなどの一時的な問題が原因である可能性のある失敗した要求を再試行するミドルウェア。

スパイダーがすべての通常の(失敗していない)ページのクロールを完了すると、失敗したページはスクレイピング・プロセスで収集され、最後に再スケジュールされます。

RetryMiddleware は次の設定で設定できます(詳細については設定ドキュメントを参照):

RETRY_ENABLED
RETRY_TIMES
RETRY_HTTP_CODES

Request.meta の dont_retry キーがTrueに設定されている場合、リクエストはこのミドルウェアによって無視されます。

RetryMiddleware 設定¶

RETRY_ENABLED¶

バージョン 0.13 で追加.

デフォルト: True

再試行ミドルウェアを有効にするかどうか。

RETRY_TIMES¶

デフォルト: 2

(最初のダウンロードに加えて)再試行する最大回数。

再試行の最大回数は、 Request.meta の max_retry_times 属性を使用してリクエストごとに指定することもできます。初期化されると、 max_retry_times メタ・キーは RETRY_TIMES 設定よりも優先されます。

RETRY_HTTP_CODES¶

デフォルト: [500, 502, 503, 504, 522, 524, 408, 429]

再試行するHTTPレスポンス・コード。その他のエラー(DNSルックアップの問題、接続の切断など)は常に再試行されます。

場合によっては、400を RETRY_HTTP_CODES に追加することもできます。これは、サーバーの過負荷を示すために使用される一般的なコードだからです。HTTPの仕様ではそうなっているため、デフォルトでは含まれていません。

RobotsTxtMiddleware¶

class scrapy.downloadermiddlewares.robotstxt.RobotsTxtMiddleware¶

このミドルウェアは、robots.txt除外標準で禁止されているリクエストを除外します。

Scrapyがrobots.txtを尊重するようにするには、ミドルウェアが有効になっており、かつ、 ROBOTSTXT_OBEY 設定が有効になっていることを確認してください。

ROBOTSTXT_USER_AGENT 設定を使用して、robots.txt ファイルでの照合に使用するユーザー・エージェント文字列を指定できます。 None の場合、リクエストで送信しているUser-Agentヘッダーまたは USER_AGENT 設定(この順序で)は、robots.txt ファイルで使用するユーザー・エージェントを決定するために使用されます。

このミドルウェアは robots.txt パーサと組み合わせる必要があります。

Scrapyには、次の robots.txt パーサがサポートされています:

RobotFileParser (デフォルト)
Reppy
Robotexclusionrulesparser
Protego

robots.txt パーサは、 ROBOTSTXT_PARSER 設定で変更できます。または、新しいパーサのサポートを実装することもできます。

Request.meta の dont_obey_robotstxt キーがTrueに設定されている場合、 ROBOTSTXT_OBEY が有効になっていても、このミドルウェアは要求を無視します。

RobotFileParser¶

RobotFileParser はPythonに組み込まれている robots.txt パーサです。パーサは、Martijn Kosterの1996年のドラフト仕様に完全に準拠しています。ワイルド・カード・マッチングのサポートはありません。Scrapyはデフォルトでこのパーサを使用します。

このパーサーを使用するには、以下を設定します:

ROBOTSTXT_PARSER 設定に scrapy.robotstxt.PythonRobotParser をセット

Robotexclusionrulesparser¶

Robotexclusionrulesparser は、 Martijn Koster's 1996 draft specification に完全に準拠しており、サポートされています。ワイルド・カード・マッチング用です。

このパーサーを使用するには:

pip install robotexclusionrulesparser を実行して、 Robotexclusionrulesparser をインストールします
ROBOTSTXT_PARSER 設定に scrapy.robotstxt.RerpRobotParser をセットします

Reppyパーサ¶

Reppy は、 Robots Exclusion Protocol Parser for C++ のPythonラッパーです。パーサーは、 Martijn Koster's 1996 draft specification に完全に準拠しており、ワイルド・カード・マッチングをサポートしています。 RobotFileParser や Robotexclusionrulesparser <http://nikitathespider.com/python/rerp/>`_ とは異なり、特に、 ``Allow と Disallow ディレクティブでは、パスの長さに基づいた最も具体的なルールがより具体的ではない(より短い)ルールより優先される、長さベースのルールを使用します。

このパーサーを使用するには:

pip install reppy を実行して Reppy をインストールします
ROBOTSTXT_PARSER 設定に scrapy.robotstxt.ReppyRobotParser をセットします

Protegoパーサ¶

Protego は、純粋なPython robots.txt パーサです。パーサは Google's Robots.txt Specification に完全に準拠しているため、ワイルドカード・マッチングをサポートし、 Reppy に類似した長さベースのルールを使用します。

このパーサーを使用するには:

pip install protego を実行して Protego をインストールします
ROBOTSTXT_PARSER 設定に scrapy.robotstxt.ProtegoRobotParser をセットします

新しいパーサのサポートの実装¶

抽象基本クラス RobotParser をサブクラス化し、以下に説明するメソッドを実装することにより、新しい robots.txt パーサーのサポートを実装できます。

DownloaderStats¶

class scrapy.downloadermiddlewares.stats.DownloaderStats¶

通過するすべてのリクエストとレスポンスと例外の統計を保存するミドルウェア。

このミドルウェアを使用するには、 DOWNLOADER_STATS 設定を有効にする必要があります。

UserAgentMiddleware¶

class scrapy.downloadermiddlewares.useragent.UserAgentMiddleware¶

スパイダーがデフォルトのユーザ・エージェントをオーバーライドできるようにするミドルウェア。

スパイダーがデフォルトのユーザー・エージェントを上書きするには、その user_agent 属性を設定する必要があります。

AjaxCrawlMiddleware¶

class scrapy.downloadermiddlewares.ajaxcrawl.AjaxCrawlMiddleware¶: メタ・フラグメントHTMLタグに基づいて「AJAXクロール可能な」ページ・バリアントを検出するミドルウェア。詳細については、https：//developers.google.com/webmasters/ajax-crawling/docs/getting-started をご覧ください。

注釈

Scrapyは、このミドルウェアがなくても、「 'http://example.com/!#foo=bar'」などのURLの「AJAXクロール可能な」ページを検出します。AjaxCrawlMiddlewareは、URLに '!#' が含まれていない場合に必要です。これは多くの場合、 'index' または 'main' のWebサイトページの場合です。

AjaxCrawlMiddleware 設定¶

AJAXCRAWL_ENABLED¶

バージョン 0.21 で追加.

デフォルト: False

AjaxCrawlMiddlewareを有効にするかどうか。 broad crawls に対して有効にすることをお勧めします。

HttpProxyMiddleware 設定¶

HTTPPROXY_ENABLED¶

デフォルト: True

HttpProxyMiddleware を有効にするかどうか。

HTTPPROXY_AUTH_ENCODING¶

デフォルト: "latin-1"

HttpProxyMiddleware のプロキシ認証のデフォルトのエンコーディング。

ダウンローダー・ミドルウェア¶