102 Processing est une réponse intermédiaire issue de la spécification WebDAV d’origine, la RFC 2518. Un serveur pouvait l’envoyer pour signaler au client qu’il avait reçu la requête complète et qu’il la traitait encore, afin que le délai d’attente du client n’expire pas pendant une opération lente, comme un COPY ou un MOVE récursif avec Depth: infinity.
La RFC 4918, qui a remplacé la RFC 2518 en 2007, a supprimé le code 102, car il était rarement implémenté. Le code reste enregistré et certains serveurs l’envoient encore, mais les nouvelles applications ne doivent pas s’appuyer dessus. Pour un traitement long, renvoyez plutôt 202 Accepted avec une URL que le client peut interroger régulièrement, ou diffusez la progression en continu.
Les clients qui ne comprennent pas le code 102 peuvent l’ignorer, comme toute réponse 1xx inattendue, et continuer d’attendre le statut final.
Exemple de réponse
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 et vérification des redirections
Les moteurs de recherche ne voient jamais 102 comme le statut d’une page ; seule la réponse finale compte. Un vérificateur de redirections indique lui aussi le statut final (souvent 207 Multi-Status pour WebDAV), car les réponses intermédiaires sont absorbées par le client HTTP.
Causes fréquentes et cas d’usage
- Un serveur WebDAV signale qu’un
COPY,MOVEouDELETErécursif et lent est toujours en cours. - Une application envoie 102 comme signal de maintien de la connexion pendant de longues requêtes. Préférez 202 Accepted avec une interrogation régulière (polling).
- Des proxys ou des clients dépassent leur délai d’attente sur des opérations longues alors que le serveur a envoyé 102. Augmentez leur délai de lecture ou rendez l’opération asynchrone.