102 Processing मूल WebDAV स्पेसिफ़िकेशन, RFC 2518, का एक अंतरिम रिस्पॉन्स है। सर्वर इसे भेजकर क्लाइंट को बता सकता था कि उसे पूरी रिक्वेस्ट मिल गई है और वह अभी उस पर काम कर रहा है, ताकि Depth: infinity के साथ रिकर्सिव COPY या MOVE जैसे धीमे ऑपरेशन के दौरान क्लाइंट का टाइमआउट न हो।
2007 में RFC 2518 की जगह लेने वाले RFC 4918 ने 102 को हटा दिया, क्योंकि इसे बहुत कम सर्वरों ने लागू किया था। यह कोड अब भी रजिस्टर्ड है और कुछ सर्वर अब भी इसे भेजते हैं, लेकिन नए ऐप्लिकेशन को इस पर निर्भर नहीं रहना चाहिए। लंबे चलने वाले काम के लिए 202 Accepted लौटाएं, साथ में एक URL दें जिसे क्लाइंट बार-बार जांच (poll) सके, या प्रोग्रेस को स्ट्रीम करें।
जो क्लाइंट 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अभी चल रहा है। - कोई ऐप्लिकेशन लंबी रिक्वेस्ट के दौरान कनेक्शन चालू रखने के संकेत (keep-alive) के रूप में 102 भेजता है। इसकी जगह पोलिंग के साथ 202 Accepted बेहतर है।
- सर्वर के 102 भेजने के बावजूद लंबे ऑपरेशन पर प्रॉक्सी या क्लाइंट का टाइमआउट हो जाता है। उनका रीड टाइमआउट बढ़ाएं या ऑपरेशन को एसिंक्रोनस बनाएं।