102 Processing è una risposta provvisoria della specifica WebDAV originale, la RFC 2518. Un server poteva inviarla per comunicare al client di aver ricevuto la richiesta completa e di starci ancora lavorando, così che il client non andasse in timeout durante un’operazione lenta come un COPY o un MOVE ricorsivo con Depth: infinity.
La RFC 4918, che nel 2007 ha sostituito la RFC 2518, ha eliminato il 102 perché era implementato di rado. Il codice è ancora registrato e alcuni server lo inviano tuttora, ma le nuove applicazioni non dovrebbero farci affidamento. Per le operazioni di lunga durata restituisci 202 Accepted con un URL che il client può interrogare periodicamente, oppure trasmetti l’avanzamento in streaming.
I client che non riconoscono il 102 possono ignorarlo, come possono ignorare qualsiasi risposta 1xx inattesa, e continuare ad attendere lo stato definitivo.
Esempio di risposta
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 e verifica dei redirect
I motori di ricerca non vedono mai un 102 come stato di una pagina: conta solo la risposta definitiva. Anche una verifica redirect riporta lo stato finale (per WebDAV spesso 207 Multi-Status), perché le risposte provvisorie vengono gestite direttamente dal client HTTP.
Cause comuni e casi d’uso
- Un server WebDAV segnala che un
COPY,MOVEoDELETEricorsivo e lento è ancora in esecuzione. - Un’applicazione invia un 102 come segnale di keep-alive durante le richieste lunghe. Meglio usare 202 Accepted con polling.
- Proxy o client vanno in timeout durante le operazioni lunghe anche se il server ha inviato un 102. Aumenta il loro timeout di lettura o rendi l’operazione asincrona.