एक तस्वीर क्यों विफल होती है जबकि पेज का बाकी हिस्सा लोड होता है
तीन शर्तें नेटवर्क खराबी को अवरुद्ध अनुरोध और रेंडरिंग त्रुटि से अलग करती हैं। रास्ता बदलने से पहले वह URL खोजें जो ब्राउज़र ने चुना था।
पेज लोड होता है, टेक्स्ट दिखता है, और एक तस्वीर टूटे हुए आइकन की तरह रह जाती है। पहली प्रतिक्रिया टनल को दोष देना है, क्योंकि टनल ही वह चीज़ है जो बदली है। उससे पहले पता करें कि ब्राउज़र ने उस तस्वीर के लिए असल में कौन-सा URL माँगा था, क्योंकि पेज का URL और तस्वीर का URL दो अलग सबूत हैं। गायब तस्वीर की अधिकांश शिकायतें ऐसे होस्ट पर पहुँचती हैं जिसे कभी काम करने वाला अनुरोध नहीं मिला, और उस जवाब में नेटवर्क पैनल पर एक नज़र ही लगती है।
कहाँ देखना है यह तीन शर्तें तय करती हैं
पहली शर्त यह है कि तस्वीर पेज वाले ही होस्ट से आती है या नहीं। अलग तस्वीर होस्ट को अपना नाम विश्लेषण, अपना कनेक्शन और अपनी TLS पहचान चाहिए, इसलिए लोड होता पेज उसके बारे में कुछ नहीं कहता।
दूसरी यह है कि ब्राउज़र ने अनुरोध भेजने से पहले उसे अवरुद्ध किया या नहीं। मिश्रित सामग्री, सामग्री सुरक्षा नीति और रेफ़रर नियम सामान्य सर्वर प्रतिक्रिया बनाए बिना तस्वीर को रोक सकते हैं, इसीलिए सूची में कोई विफल अनुरोध नहीं दिखता।
तीसरी यह है कि डिलीवरी सफल हुई और रेंडरिंग विफल हुई, ऐसा मामला जिसमें बाइट्स आ जाते हैं और तस्वीर फिर भी नहीं दिखती। इन तीन शर्तों के तीन अलग मालिक हैं, और केवल पहली ही नेटवर्क का सवाल है।
| What you see | Where the fault sits |
|---|---|
| Request absent from the list | Markup, lazy loading or a policy that blocked it |
| Request failed or timed out | Resolution, route, TLS or the image host itself |
| Request returned 200, image blank | Response type, decoding or rendering |
वह संसाधन खोजें जिसे ब्राउज़र ने असल में चुना
पेज के स्रोत में जो URL आप देखते हैं वह अक्सर वही URL नहीं होता जो माँगा गया था। स्रोत-समुच्चय, picture तत्व और CSS पृष्ठभूमि सभी ब्राउज़र को व्यूपोर्ट की चौड़ाई, पिक्सेल घनत्व या प्रारूप समर्थन के आधार पर अलग संसाधन चुनने देते हैं। आलसी लोड होती तस्वीर तब तक शायद माँगी ही न जाए जब तक पेज किसी खास स्थिति में न पहुँचे।
तत्व और अनुरोध को साथ जाँचें, और समस्या बताते समय अनुरोध के साथ इनिशिएटर रखें। MDN का इमेज तत्व संदर्भ स्रोत चयन, लोडिंग व्यवहार और रेफ़रर नियंत्रण एक ही जगह समझाता है, जो यह बताने के लिए काफी है कि किस विशेषता ने विफल URL चुना।
होस्टनाम, स्थिति, कोई भी रीडायरेक्ट श्रृंखला और प्रतिक्रिया का सामग्री प्रकार दर्ज करें। साइन-इन पेज लौटाने वाला 200 प्रतिक्रिया इस्तेमाल लायक तस्वीर नहीं है, और HTML त्रुटि पेज पर रीडायरेक्ट टूटी फ़ाइल जैसा ही दिखता है, जब तक आप प्रकार न पढ़ें।
नेटवर्क से पहले स्थिति पढ़ें
समय-समाप्ति, अस्वीकृत अनुरोध और डिकोडिंग त्रुटि को अलग अगले कदम चाहिए, और स्थिति कोड ही उन्हें अलग करता है। समय-समाप्ति नाम विश्लेषण, मार्ग या ऐसे होस्ट की ओर इशारा करती है जो जवाब नहीं दे रहा। अस्वीकृत अनुरोध नीति या प्राधिकरण परत की ओर इशारा करता है। डिकोडिंग त्रुटि बाइट्स या प्रारूप की ओर इशारा करती है।
अगर अनुरोध बिलकुल न दिखे, तो नेटवर्क देखना बंद करें और मार्कअप देखें। सबसे आम कारण स्रोत-समुच्चय में ऐसी प्रविष्टि है जिसे ब्राउज़र ने पसंद किया और जो अब सर्वर पर नहीं है, और उसके बाद ऐसा तत्व जिसे किसी स्क्रिप्ट ने कभी दृश्यमान नहीं बनाया।
यही अंतर इस तरह की शिकायतों में ज़्यादातर बर्बाद मेहनत रोकता है।
जब ब्राउज़र इसे अवरुद्ध करता है, तो पढ़ने के लिए कोई प्रतिक्रिया नहीं होती
मिश्रित सामग्री क्लासिक मामला है: सादे HTTP पर तस्वीर माँगता HTTPS पेज अनुरोध को विफल के बजाय अवरुद्ध पाता है, और कंसोल कारण दर्ज करता है। सामग्री सुरक्षा नीति भी वही आकार बनाती है, संदेश में अवरुद्ध निर्देश का नाम होता है। हेडर हटाने वाली रेफ़रर नीति भी हॉटलिंक-संरक्षित होस्ट को तस्वीर के बजाय प्लेसहोल्डर लौटाने पर मजबूर कर सकती है।
नेटवर्क मार्ग को छूने से पहले दर्ज कारण पढ़ें, क्योंकि मार्ग बदलने से ये अवरोध ठीक नहीं होते। क्रॉस-ओरिजिन अनुमतियाँ जोड़ना भी समाधान नहीं है: दूसरे होस्ट की तस्वीर दिखाना और कैनवास में उसके पिक्सेल पढ़ना अलग क्रियाएँ हैं, और सिर्फ़ दूसरी को ही वे हेडर चाहिए जो लोग चिपकाते हैं।
जिस साइट का आप प्रबंधन करते हैं, उसमें संसाधन का URL, प्रतिक्रिया या नीति उसके मालिक के पास ठीक करें और प्राधिकरण तथा रेफ़रर की शर्तें अक्षुण्ण रखें। जिस साइट को आप नियंत्रित नहीं करते, उसमें पेज और अनुरोध के सबूत उसके सहायता चैनल को भेजें, निजी या समाप्त होते संसाधन लिंक दोबारा प्रकाशित करने के बजाय।
सबूत बदले बिना रास्तों की तुलना करें
अगर आप सचमुच पहुँच मार्ग जाँचना चाहते हैं, तो बाकी सब स्थिर रखें: वही पेज, वही खाता, वही चुनी गई तस्वीर, एक अनुमत मार्ग बदला गया। रेंडर हुए परिणाम के बजाय अनुरोध प्रविष्टियों की साथ-साथ तुलना करें, क्योंकि रेंडर हुआ परिणाम बताता है कि तस्वीर दिखी या नहीं, क्यों नहीं।
नए मार्ग पर लोड होती तस्वीर यह साबित नहीं करती कि वह मार्ग अधिकृत है, और टूटी रहती तस्वीर यह साबित नहीं करती कि टनल दोषी है। अगर तस्वीर हटा दी गई है या पहुँच जानबूझकर सीमित है, तो प्रमाणपत्र जाँच बंद करने या किसी और की सुरक्षित सामग्री की नकल करने के बजाय समर्थित विकल्प इस्तेमाल करें।
काम का क्रम: चुना गया URL पहचानें, उसकी स्थिति और प्रकार पढ़ें, दर्ज अवरोध कारण जाँचें, फिर एक बार में एक मार्ग परिवर्तन की तुलना करें।