आपका क्लाइंट साठ सेकंड प्रतीक्षा करने को तैयार है। दस सेकंड बाद उसे HTTP 504 मिलता है। क्लाइंट का टाइमआउट दो मिनट करने से गेटवे को पचास सेकंड अधिक काम नहीं मिलता।

504 ऐसे गेटवे या प्रॉक्सी का वर्णन करता है जिसे अनुरोध पूरा करने का प्रयास करते समय समय पर अपस्ट्रीम प्रतिक्रिया नहीं मिली। गेटवे अपना निर्णय लेकर प्रतिक्रिया लौटा चुका है। आपका क्लाइंट उस प्रतिक्रिया को सफलतापूर्वक पढ़ सकता है।

इसे किस मध्यस्थ ने लौटाया?

फ़ॉरवर्ड प्रॉक्सी जारीकर्ता हो सकता है। वेबसाइट द्वारा संचालित बाद का गेटवे भी हो सकता है। CONNECT के भीतर सामान्य एंड-टू-एंड TLS के साथ, उस सुरक्षित गंतव्य-विनिमय के भीतर से आई HTTP प्रतिक्रिया स्वयं CONNECT के अस्वीकरण के समान नहीं है।

चरण, प्रतिक्रिया हेडर, त्रुटि पृष्ठ का शब्दांकन और उपलब्ध होने पर मेल खाते लॉग सहेजें। सर्वर लेबल एक संकेत हो सकता है, पर उसे अचूक आरोपण नहीं मानना चाहिए। मार्ग में आपके क्लाइंट में कॉन्फ़िगर किए गए एक से अधिक मध्यस्थ हो सकते हैं।

फिर जाँचें कि वह अपस्ट्रीम कार्रवाई पूरी क्यों नहीं हुई। पहुँच, अधिभारित सेवाएँ, ऐसा अनुरोध निकाय जिसे अपस्ट्रीम अपेक्षा के अनुसार संसाधित नहीं कर सकता, और अनुप्रयोग का व्यवहार — सब मायने रख सकते हैं। केवल संख्यात्मक स्थिति यह सिद्ध नहीं करती कि User-Agent बदलना या एक टाइमआउट विकल्प जोड़ना सार्वभौमिक समाधान है।

उसी अनुरोध की तुलना करें

जब कोई दूसरा टूल काम करे, तो विधि, लक्ष्य, निकाय एन्कोडिंग, प्रमाणीकरण और मार्ग की तुलना करें। "URL ब्राउज़र में खुलता है" सेवा क्लाइंट के माध्यम से multipart सबमिशन की पूरी तुलना नहीं है।

यदि आप जारीकर्ता गेटवे चलाते हैं, तो उसका अपस्ट्रीम बजट समर्थित कार्यभार और आसपास की समय-सीमाओं के अनुरूप रखें। यदि नहीं, तो उसका परिणाम साक्ष्य के रूप में रखें और ऑपरेटर के प्रलेखित पहुँच या सहायता मार्ग का उपयोग करें। स्थानीय रूप से अधिक देर तक प्रतीक्षा करना पहले ही आ चुकी प्रतिक्रिया को नहीं बदल सकता।

संबंधित लेख