102 Processing to odpowiedź pośrednia z pierwotnej specyfikacji WebDAV, RFC 2518. Serwer mógł ją wysłać, aby poinformować klienta, że odebrał całe żądanie i wciąż nad nim pracuje. Dzięki temu klient nie przerywał połączenia po przekroczeniu limitu czasu podczas powolnej operacji, takiej jak rekurencyjne COPY lub MOVE z Depth: infinity.
RFC 4918, który w 2007 roku zastąpił RFC 2518, usunął kod 102, ponieważ rzadko go implementowano. Kod nadal figuruje w rejestrze i niektóre serwery wciąż go wysyłają, ale nowe aplikacje nie powinny na nim polegać. Przy długotrwałych operacjach zwracaj 202 Accepted z adresem URL, który klient może odpytywać, albo przesyłaj informacje o postępie strumieniowo.
Klienci, którzy nie rozumieją kodu 102, mogą go zignorować, tak jak każdą nieoczekiwaną odpowiedź 1xx, i dalej czekać na kod końcowy.
Przykładowa odpowiedź
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 i sprawdzanie przekierowań
Wyszukiwarki nigdy nie widzą kodu 102 jako kodu odpowiedzi strony; liczy się tylko odpowiedź końcowa. Narzędzie do sprawdzania przekierowań również pokazuje kod końcowy (w przypadku WebDAV często 207 Multi-Status), ponieważ odpowiedzi pośrednie obsługuje sam klient HTTP.
Typowe przyczyny i zastosowania
- Serwer WebDAV informuje, że powolna rekurencyjna operacja
COPY,MOVElubDELETEwciąż trwa. - Aplikacja wysyła kod 102 jako sygnał podtrzymania połączenia podczas długich żądań. Lepiej zwrócić 202 Accepted i pozwolić klientowi odpytywać o stan.
- Serwery proxy lub klienci przerywają długie operacje po przekroczeniu limitu czasu, mimo że serwer wysłał 102. Zwiększ ich limit czasu odczytu albo przekształć operację w asynchroniczną.