102 Processing — промежуточный ответ из первой спецификации WebDAV, RFC 2518. С его помощью сервер мог сообщить клиенту, что получил запрос целиком и все еще обрабатывает его, чтобы клиент не прервал соединение по тайм-ауту во время медленной операции, например рекурсивного COPY или MOVE с Depth: infinity.
В RFC 4918, который в 2007 году заменил RFC 2518, код 102 убрали, потому что его почти никто не реализовал. Код по-прежнему зарегистрирован, и некоторые серверы до сих пор его отправляют, но новым приложениям не стоит на него полагаться. Для длительных операций возвращайте 202 Accepted с URL, который клиент может периодически опрашивать, или передавайте ход выполнения потоком.
Клиенты, которые не понимают 102, могут его проигнорировать, как и любой неожиданный ответ 1xx, и продолжить ждать окончательный код ответа.
Пример ответа
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 в качестве кода ответа страницы: учитывается только окончательный ответ. Проверка редиректов тоже показывает окончательный код (для WebDAV это часто 207 Multi-Status), потому что промежуточные ответы обрабатывает сам HTTP-клиент.
Типичные причины и сценарии использования
- Сервер WebDAV сообщает, что медленная рекурсивная операция
COPY,MOVEилиDELETEеще выполняется. - Приложение отправляет 102 как keep-alive-сигнал во время долгих запросов. Лучше используйте 202 Accepted с опросом статуса.
- Прокси или клиенты прерывают долгие операции по тайм-ауту, хотя сервер отправил 102. Увеличьте у них тайм-аут чтения или сделайте операцию асинхронной.