102 Processing ist eine vorläufige Antwort aus der ursprünglichen WebDAV-Spezifikation RFC 2518. Ein Server konnte damit signalisieren, dass er die vollständige Anfrage erhalten hatte und noch daran arbeitete, damit beim Client während einer langsamen Operation wie einem rekursiven COPY oder MOVE mit Depth: infinity kein Timeout auftrat.
RFC 4918, das RFC 2518 im Jahr 2007 ablöste, hat 102 gestrichen, weil der Code kaum implementiert wurde. Er ist weiterhin registriert, und manche Server senden ihn noch, neue Anwendungen sollten sich aber nicht darauf verlassen. Für lang laufende Vorgänge geben Sie besser 202 Accepted mit einer URL zurück, die der Client abfragen kann, oder streamen den Fortschritt.
Clients, die 102 nicht kennen, dürfen den Code ignorieren, wie jede unerwartete 1xx-Antwort, und warten weiter auf den endgültigen Status.
Beispielantwort
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 und Weiterleitungsprüfung
Suchmaschinen sehen 102 nie als Seitenstatus; es zählt nur die endgültige Antwort. Auch ein Redirect-Checker meldet den endgültigen Status (bei WebDAV oft 207 Multi-Status), weil vorläufige Antworten vom HTTP-Client intern verarbeitet werden.
Häufige Ursachen und Einsatzzwecke
- Ein WebDAV-Server meldet, dass ein langsames rekursives
COPY,MOVEoderDELETEnoch läuft. - Eine Anwendung sendet 102 als Keep-Alive-Signal während langer Anfragen. Besser ist 202 Accepted mit Polling.
- Proxys oder Clients brechen lange Operationen mit einem Timeout ab, obwohl der Server 102 gesendet hat. Erhöhen Sie deren Read-Timeout oder machen Sie die Operation asynchron.