102 Processing は、最初の WebDAV 仕様である RFC 2518 で定義された暫定レスポンスです。サーバーはこれを送ることで、リクエストをすべて受信し、まだ処理中であることをクライアントに伝えられました。Depth: infinity を指定した再帰的な COPY や MOVE のように時間のかかる操作の途中で、クライアントがタイムアウトしないようにするためです。
2007 年に RFC 2518 を置き換えた RFC 4918 では、ほとんど実装されていなかったことから 102 が削除されました。このコードは現在も登録されており、送信するサーバーもまだありますが、新しいアプリケーションでは頼るべきではありません。時間のかかる処理には、クライアントがポーリングできる URL を付けて 202 Accepted を返すか、進捗をストリーミングしてください。
102 を解釈できないクライアントは、想定外の 1xx レスポンス全般と同じくこれを無視して、最終ステータスを待ち続けることができます。
レスポンス例
HTTP
HTTP/1.1 102 Processing
HTTP/1.1 207 Multi-Status
Date: Fri, 06 Nov 2026 10:15:32 GMT
Content-Type: application/xml; charset=utf-8
Transfer-Encoding: chunkedSEO とリダイレクトチェック
検索エンジンが 102 をページのステータスとして目にすることはなく、評価されるのは最終レスポンスだけです。暫定レスポンスは HTTP クライアントが内部で処理するため、リダイレクトチェッカーも最終ステータス（WebDAV では多くの場合 207 Multi-Status）を表示します。
よくある原因と主な用途
- 時間のかかる再帰的な
COPY、MOVE、DELETEがまだ実行中であることを、WebDAV サーバーが知らせている場合。 - 長いリクエストの間のキープアライブ信号として、アプリケーションが 102 を送っている場合。ポーリングと組み合わせた 202 Accepted を使うほうが適切です。
- サーバーが 102 を送っているのに、時間のかかる操作でプロキシやクライアントがタイムアウトする場合。読み取りタイムアウトを延ばすか、操作を非同期にしてください。