कुछ Tumblr पृष्ठों की छवियां लोड क्यों नहीं होती हैं, लेकिन उन पर काम का उपयोग करते हुए?

Question

किसी मित्र को उनके इंटरनेट कनेक्शन के साथ मदद करना क्योंकि "कुछ पेज लोड नहीं हुए हैं", मैंने देखा कि समस्या यह थी कि कुछ ब्लॉग के छवि पोस्ट के ब्राउज़र पर लोड नहीं हो रहे थे। मुझे निम्नलिखित कारणों से यह अजीब लगा:

1. केवल वे चित्र जो पोस्ट का हिस्सा हैं, वे लोड नहीं हुए हैं। उपयोगकर्ता अवतार, बैनर, हेडर, विभिन्न थीम और / या पृष्ठ-संबंधित छवियां अभी भी दिखाई देती हैं।
2. कंप्यूटर पर किसी भी ब्राउज़र के साथ होता है (विज्ञापन / स्क्रिप्ट ब्लॉकर्स के साथ और बिना फ़ायरफ़ॉक्स और क्रोम / ium दोनों पर परीक्षण किया गया)।
3. का उपयोग करते हुए wget छवियों के प्रत्यक्ष लिंक पर काम करता है।
4. यह सभी टम्बलर पृष्ठों पर लागू नहीं होता है। अधिकांश ठीक से लोड होते हैं, लेकिन उन पोस्ट वाले पृष्ठों की एक सूची बनाते समय जो चित्र लोड नहीं करते हैं वे बताते हैं कि वे ज्यादातर उपयोगकर्ताओं के एक ही समूह से हैं।
5. समस्या इस अर्थ में ब्लॉग-विशिष्ट प्रतीत होती है कि यदि किसी निश्चित ब्लॉग की छवि पोस्ट ब्राउज़र में लोड नहीं होती है, तो अन्य ब्लॉग (अप्रभावित या नहीं) जो उसी पोस्ट को पुन: प्रकाशित करते हैं, वह ब्राउज़र में भी छवि को लोड नहीं करेगा। इसके विपरीत, यदि एक प्रभावित ब्लॉग एक अप्रभावित से बगावत करता है, तो छवि ठीक लोड होती है।
6. चित्र उपयोगकर्ता द्वारा बनाए गए Tumblr पोस्ट से हैं जहाँ उपयोगकर्ता पोस्ट करने के लिए एक छवि अपलोड करता है और Tumblr द्वारा होस्ट किया जाता है। उदाहरण के लिए (यह उदाहरण प्रभावित ब्लॉगों में से एक नहीं है), में यह छवि पोस्ट (बेतरतीब ढंग से चुनी), इस पोस्ट में छवि का सीधा लिंक होगा। छवि पोस्ट स्वचालित रूप से छवियों को एक लिंक बनाती हैं Tumblr में एक और पेज (आमतौर पर) का उपयोग करना बड़ा संस्करण पोस्ट में उपयोग की जाने वाली छवि जो कि उपयोगकर्ता द्वारा पोस्ट के लिए अपलोड किए गए आकार के करीब है।

संभवतः ऐसा होने का कारण क्या हो सकता है? वास्तव में मुझे जो हिस्सा मिलता है, वह तथ्य यह है कि wget काम करता है, इसलिए मुझे लगता है कि मैं यह मान सकता हूं कि यह नेटवर्क कनेक्शन की समस्या नहीं है।

अद्यतन करें:

यहाँ एक विद्रोही पोस्ट का एक उदाहरण है जो ब्राउज़रों पर लोड करने में विफल रहता है। मुख्य ब्लॉग अन्य छवि पोस्ट हैं जो ठीक से लोड होती हैं। इस पोस्ट में छवि का सीधा लिंक है और यहाँ बड़े संस्करण के लिए एक (दोनों यहाँ लोड नहीं है)। wget दोनों के लिए काम करता है, लेकिन फ़ायरफ़ॉक्स के साथ किसी भी सीधे लिंक पर जाने पर, यह त्रुटि दिखाई देती है:

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<Error>
    <Code>AccessDenied</Code>
    <Message>Access Denied</Message>
    <RequestId>A626307DF577B411</RequestId>
    <HostId>J9GxX1HY9vX3ElWjYf7M48ByvKXLRIwRBJ2al2voS3J/C+WhILWHyd3crFhhNtkXuvG0zaxBTxw=</HostId>
</Error>

RequestID तथा HostId हर बार बदलता है। मेरे मित्र और मैं फिलीपींस में स्थित हैं।

अपडेट [2014/03/08]

आगे के परीक्षणों और टंबलर समर्थन के ईमेल का जवाब देने पर, wget कुछ अवसरों पर काम करना (प्रत्यक्ष लिंक पर 403 त्रुटियां प्राप्त करना) बंद कर दिया है।

अपडेट [2014/03/09]

HTTPS-Everywhere के लिए Tumblr नियमों को बंद करना लगता है कभी कभी समस्या का समाधान कीजिए।

---

_{ध्यान दें:}

• _{# 6 के उदाहरण में, सीधे लिंक दोनों एक ही छवि को इंगित करते हैं। आमतौर पर, हालांकि, छवि पोस्ट में (ज़ूम करने योग्य छवि पृष्ठ की तुलना में) का उपयोग किया जाता है, पृष्ठ के विषय को फिट करने के लिए छवि के एक छोटे संस्करण का उपयोग करता है। उदाहरण बड़ी स्क्रीन के लिए बनाई गई थीम का उपयोग करता है ताकि उसे छोटे संस्करण की आवश्यकता न हो।}

Comments

क्या मैंने 5 सही ढंग से पढ़ा, वह अन्य लोग उन छवियों को नहीं देख सकते हैं जो इस मुद्दे के साथ व्यक्ति द्वारा विद्रोह कर रहे हैं?

— Paul

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

— JakeGould

@Paul का मतलब था कि अगर मुझे tumblrUser1 द्वारा एक ऐसी छवि पोस्ट दिखाई देती है जो ब्राउज़र पर लोड नहीं होती है और यदि tumblrUser2, tumblrUser3 ... tumblrUserN, तो हम आपको उन अन्य उपयोगकर्ताओं के पृष्ठ पर लोड नहीं कर पाएंगे ।

— maki57

आपके द्वारा दिखाए गए उदाहरण सभी PNG चित्र हैं। आपके मित्र का ऑपरेटिंग सिस्टम क्या है? कृपया स्पष्ट करने के लिए प्रश्न को संपादित करें। यह PNG चित्रों से जुड़ा एक मुख्य OS मुद्दा हो सकता है।

— JakeGould

@Paul का मतलब था कि अगर मुझे tumblrUser1 द्वारा एक ऐसी छवि पोस्ट दिखाई देती है जो मेरे वर्तमान ब्राउज़र पर लोड नहीं होती है और यदि tumblrUser2, tumblrUser3 ... tumblrUserN, तो हम आपको उन अन्य उपयोगकर्ताओं पर छवि लोड नहीं कर पाएंगे 'पृष्ठ।

— maki57

Answer 1

अद्यतन करें: ऐसा लगता है कि जिस तरह से तने को लोड नहीं किया गया है, उससे छवियों के साथ मूल मुद्दा है EFF का HTTPS हर जगह प्लग इन / एक्सटेंशन कुछ Tumblr URL को संभाला। डेवलपर को सूचित किया गया और एक तय जगह पर दिखाई देता है । यह उत्तर मूल रूप से प्रारंभिक प्रश्न द्वारा उल्लिखित मुद्दे को उजागर करने के लिए किए गए जासूसी कार्य को तोड़ता है और भविष्य में इसी तरह का मुद्दा दिखाई देने पर आगे डीबगिंग / निदान के लिए उपयोगी साबित हो सकता है।

---

संपादित करें: छवि जोंक के बारे में बड़ी सामग्री अमान्य लगती है। तो शीर्ष पर एक नया विचार जोड़ देगा और छवि लेचिंग जानकारी को नीचे छोड़ देगा बस किसी के लिए यह उपयोगी है।

अमेज़न CloudFront CDN विचार

ठीक है, आपके द्वारा प्रदत्त URL का उपयोग करने के साथ-साथ अमेज़ॅन CloudFront CDN सेटअप के साथ मेरे वास्तविक दुनिया के कुछ अनुभव - मुझे लगता है कि मैंने कुछ खोजा है। ऐसा लगता है जैसे Tumblr का Amazon CloudFront CDN config किसी कारण से घुट रहा है। यहाँ मुझे लगता है कि ऐसा ही है।

आइए इस उदाहरण URL को लेते हैं:

http://36.media.tumblr.com/d685b02fdf2d3f167c22d9a97e27e87a/tumblr_nfpq5qPZ4v1tognpro1_1280.png

अब चलने दो curl -I उस फ़ाइल पर हेडर जानकारी प्राप्त करने के लिए:

curl -I http://36.media.tumblr.com/d685b02fdf2d3f167c22d9a97e27e87a/tumblr_nfpq5qPZ4v1tognpro1_1280.png

इसके लिए आउटपुट कुछ इस तरह होगा:

HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 782141
Connection: keep-alive
Accept-Ranges: bytes
Cache-Control: max-age=1209600
Date: Thu, 05 Mar 2015 02:15:44 GMT
Server: nginx
X-Cache: Miss from cloudfront
Via: 1.1 7e54fc06cd70e4752fe050bbe5c130be.cloudfront.net (CloudFront)
X-Amz-Cf-Id: QyIUyzfaJJN3PU_xWkW0P-D2kjg_1cVenKzFAoY2PubgZQlBHWorZQ==

अब यहाँ ध्यान देने वाली बातें हैं Date (CloudFront समापन बिंदु पर फ़ाइल की तिथि और समय) और X-Cache (अमेज़न सामग्री वितरण की स्थिति) हेडर। अमेज़ॅन क्लाउडफ़ॉरेस्ट पर विशिष्ट व्यवहार पहली पहुंच है जो "मिस फ्रॉम क्लाउडफ्रंट" को व्यक्त करेगा और फिर यदि आप दूसरा काम करेंगे curl -I इसके तुरंत बाद एक होना चाहिए Hit from cloudfront।

लेकिन ऐसा नहीं है जो मैंने अभी देखा है। यहाँ एक का टूटना है Date तथा X-Cache मेरे द्वारा किए गए अभिगम का एक गुच्छा की स्थिति:

• Date: Thu, 05 Mar 2015 02:19:37 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:39 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:44 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Hit from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Hit from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Hit from cloudfront

कारण वही सटीक डेटा वाले कई आइटम हैं जो हैं Hit from cloudfront अंत के पास क्योंकि सीडीएन पर ऐसा ही होता है: यदि सीडीएन के समापन बिंदु में फ़ाइल है, तो Date उस फ़ाइल की वास्तविक निर्माण / संशोधन तिथि से संबंधित है जो समापन बिंदु है।

आप अलग-अलग तिथियों / समयों के साथ पहले चार पहुंच को अलग-अलग करते हैं और वे सभी हैं Miss from cloudfront, सही? इसका मतलब है कि सीडीएन एंडपॉइंट अभी वापस गूंज रहा है कि उस समय उस फ़ाइल को एक्सेस करने का प्रयास किया गया था और सभी प्रयास छूट गए थे।

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

जो सभी कहना है, मुझे नहीं लगता कि यह आसानी से ग्राहक की ओर से साफ किया जा सकता है।

---

संपादित करें: इसलिए मूल पोस्टर ने कुछ नए URL जोड़े, और यह अभी भी एक सर्वर-साइड मुद्दे की ओर इशारा करता है, लेकिन मैं सिर्फ रिकॉर्ड के लिए विवरण पोस्ट करना चाहता था।

एजकास्ट & amp; सीडीएन आइडियाज को हाइलाइट करता है

इसलिए मूल पोस्टर में और अधिक विवरण जोड़े गए हैं, इसलिए यहां उस ब्लॉग पोस्ट के आधार पर अधिक विवरण हैं जो एक उदाहरण के रूप में उपयोग किया जा रहा है:

http://claystorks.tumblr.com/post/112741831192/soulmister-claystorks-windspeare-explain

और ये चित्र URL उस पोस्ट के URL के उदाहरण के रूप में दिए गए हैं:

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_500.png

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_1280.png

और वे दो छवि URL वास्तव में विफल होते हैं। लेकिन मेरी तरफ से - ब्रुकलिन, न्यू यॉर्क, यूएसए से ब्लॉग पोस्ट के मूल सूपर कोड को देखकर- मैं उन एजस्टॉस्ट को नहीं देख रहा हूं ( gs1.wac.edgecastcdn.net ) यूआरएल। बल्कि, ये वे URL हैं जिन्हें मैं देख रहा हूँ:

http://41.media.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_500.png

http://41.media.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_1280.png

तो मेरा पहला विचार है कि मूल पोस्टर उन एजकास्ट को क्यों देख रहा है ( gs1.wac.edgecastcdn.net )। लेकिन तब अगर मैं एक अनुरेखक करने के लिए 41.media.tumblr.com मुझे लगता है कि एक सर्वर Highwinds ((?!)?) द्वारा प्रबंधित किया जाता है। इसके विपरीत मूल उपयोगकर्ता द्वारा पारित प्रारंभिक यूआरएल का उपयोग कर रहे हैं 36.media.tumblr.com hostname और आप देख सकते हैं कि वे Amazon CloudFront CDN सर्वर द्वारा प्रबंधित हैं।

यह सब कहना है - जो मैंने पहले कहा था - यह सब Tumblr और उनके CDN प्रबंधन के साथ एक सर्वर साइड मुद्दा लगता है। लेकिन मेरी तरफ से- ब्रुकलिन, न्यूयॉर्क, यूएसए में- मैं हाईविंड सीडीएन सर्वरों के साथ-साथ अमेज़ॅन क्लाउडफ्रंट सीडीएन सर्वरों से अपेक्षित सामग्री को स्पष्ट रूप से देख रहा हूं। ये EdgeCast URL कहाँ से आ रहे हैं या कैसे / क्यों विफल हो रहे हैं, यह ग्राहक के पक्ष में किसी के नियंत्रण से बाहर है। यह निश्चित रूप से Tumblr के तकनीकी कर्मचारियों से संपर्क करने के लिए कुछ होगा क्योंकि कोई ऐसा तरीका नहीं है जिससे डेस्कटॉप एंड-यूज़र इसे हल कर सके।

---

छवि लीचिंग विचार

अब प्रासंगिक नहीं हो सकता है, लेकिन यहां संदर्भ के लिए है।

आप यह बताते हुए मुझे एक सुराग दे:

का उपयोग करते हुए wget छवियों के प्रत्यक्ष लिंक पर काम करता है।

कई साइटों में नियम होते हैं- आमतौर पर अपाचे के माध्यम से सेट किए जाते हैं - जो इमेज लीचिंग को रोकते हैं। उन नियमों के काम करने के तरीके के बारे में अधिक जानकारी यहां प्रदान किए गए हैं और इसे संक्षेप में प्रस्तुत किया गया है:

.Htaccess का उपयोग करके, आप अपने सर्वर पर हॉट लिंकिंग को हटा सकते हैं, इसलिए   उदाहरण के लिए, आपकी साइट पर एक छवि या CSS फ़ाइल से लिंक करने का प्रयास   या तो अवरुद्ध है (असफल अनुरोध, जैसे टूटी हुई छवि) या सेवा की   विभिन्न सामग्री (यानी: एक क्रोधी आदमी की छवि)।

आपके विवरण के आधार पर — और इस तथ्य के माध्यम से आप छवियों तक पहुँच सकते हैं wget -मुझे विश्वास है कि आपके द्वारा जारी की जा रही छवियों को उपयोगकर्ताओं द्वारा Tumblr पर होस्ट नहीं किया गया है, बल्कि ऐसी छवियां हैं जिन्हें Tumblr ब्लॉग पर रखा गया है लेकिन वास्तव में किसी अन्य साइट पर होस्ट की गई हैं।

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

इसलिए जब आप इमेज को एक्सेस कर रहे हैं wget आप छवि को सीधे एक्सेस कर रहे हैं। इसलिए इमेज लीचिंग के नियम में कोई कमी नहीं आएगी। इस प्रकार आप इमेज को प्राप्त कर सकते हैं wget लेकिन तब नहीं जब यह दूसरे पेज में इंबेडेड हो।

Comments

वे Tumblr द्वारा होस्ट की गई Tumblr छवि पोस्ट हैं। मैं वर्णन संपादित करूँगा।

— maki57

मुझसे गलती हो सकती है, लेकिन मुझे लगा कि Tumblr ने EdgeCast का इस्तेमाल किया है। किसी भी तरह से, बहुत दिलचस्प स्पष्टीकरण के लिए धन्यवाद। क्या यह तब भी लागू होता है जब मैंने सवाल में अपडेट को जोड़ा है?

— maki57

@ maki57 Tumblr की तरह लगता है, Amazon CloudFront, EdgeCast और Highwinds को अपनी साइटों से CDN सामग्री परोसने के लिए उपयोग करता है। और ब्रुकलिन में मेरे सहूलियत के बिंदु से, NY मैं इस त्रुटि को पुन: पेश नहीं कर सकता; वे एडगॉस्ट URL मेरे लिए विफल हैं, लेकिन आप जिस पृष्ठ से मुझे लिंक करते हैं, वह मुझे हाइवांड सीडीएन देता है। मेरे उत्तर में अधिक विवरण, लेकिन यह एक सर्वर-साइड मुद्दा है जिसे टम्बलर के साथ लाने की आवश्यकता है। अब इस प्रश्न को बंद करने के लिए मतदान करेंगे क्योंकि यह वास्तव में ऐसा कुछ नहीं है जिसे आप डेस्कटॉप से ​​हल कर पाएंगे जो कि इस साइट के बारे में है।

— JakeGould

आप अभी भी "क्यों" के मेरे मुख्य प्रश्न का उत्तर देने में सक्षम थे, इसलिए मैं अभी भी इसके लिए आपको बहुत धन्यवाद देता हूं। मैं जल्द ही इसे Tumblr को रिपोर्ट करूँगा। इस बीच, मैं सिर्फ अपने मित्र को उपयोग करने के लिए कहूंगा wget अभी के लिए।

— maki57

@ maki57 खैर, क्या देख रहे हैं हर जगह HTTPS करता है और Tumblr के विशिष्ट नियम ऐसा लगता है कि प्लगइन जिस तरह से HTTPS के साथ Tumblr सौदों में एक दोष को उजागर कर सकता है। वह प्लगइन HTTPS को मजबूर करता है, और वे आपके द्वारा जारी किए जा रहे URL से प्रतीत होता है कि "HTTPS Everywhere" सभी संपत्तियों का उपयोग करने के लिए बाध्य करता है। जो कि Tumblr पर आधारित है पराक्रम काम करते हैं, लेकिन यह भी हो सकता है कि Tumblr अपने EdgeCast HTTPS सर्वर को ठीक से सिंक न करे? मैं "HTTPS एवरीवेयर" के डेवलपर्स को भी जाने दूंगा।

— JakeGould

Answer 2

मुझे इस समय बहुत समस्या हो रही है। यह काम के लिए एक सुरक्षित है - अच्छी तरह से यह एक मूर्खतापूर्ण हास्य है- एक प्रभावित ब्लॉग का उदाहरण ।

हालांकि अगर यह पाया गया कि समस्या केवल मेरे लिए क्रोम में हुई थी। थोड़ी देर बाद, मुझे एहसास हुआ कि इस मुद्दे का कारण विस्तार था " हर जगह HTTPS । "जब मैंने इसे फ़ायरफ़ॉक्स में स्थापित किया, तो मुझे वहाँ भी यही समस्या थी। और वास्तव में, अगर मैं HTTPS नियम "Tumblr (आंशिक)" को अक्षम करता हूं (जो मुझे लगता है कि इसका मतलब है *.tumblr.com ), यह फिर से ठीक काम करता है।

तो, मुद्दा यह है कि कम से कम लगता है कभी कभी , जब HTTPS का उपयोग किसी इमेज को एक्सेस करने के लिए किया जाता है, तो आपको एक अमान्य एजकास्ट URL पर पुनर्निर्देशित किया जाता है। उदाहरण के लिए, यह छवि URL ठीक काम करता है:

http://36.media.tumblr.com/57d2af15f7b21037364125f9f32c4379/tumblr_nktjzyNkv91s667kio1_1280.png

लेकिन अगर आप प्रोटोकॉल को बदलते हैं http सेवा मेरे https आप इस URL पर पुनर्निर्देशित हो जाते हैं जो काम नहीं करता है:

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/57d2af15f7b21037364125f9f32c4379/tumblr_nktjzyNkv91s667kio1_1280.png

मुझे यकीन नहीं है कि यह Tumblr की ओर से त्रुटि के रूप में गिना जाता है या नहीं। मुझे लगता है कि अगर ग्राहक HTTPS के साथ अपने मीडिया सर्वर तक नहीं पहुँच पाते हैं तो आप वास्तव में इसके लिए उन्हें दोषी नहीं ठहरा सकते।

संपादित करें: और वास्तव में समस्या से निपटा गया लगता है जैसा कि इस GitHub धागे में बताया गया है ।

Answer 3

मैंने अपने मोबाइल वाहक, टी-मोबाइल पर इस व्यवहार को अधिक देखा है। मुझे लगता है कि यह छवि आकार के आधार पर ट्रैफ़िक को आकार देने के कुछ प्रकार है या कुछ वाहक ने कहा कि आइटम को पुनः प्राप्त करने में "कठिनाई मीट्रिक" का निर्माण किया गया है।

पिछले परीक्षण में - एक साल पहले - फिर मैंने उस मित्र को टूटी हुई पोस्ट साझा की, जिसके पास वेरिज़ोन है, और छवि ठीक है।

हालांकि मैं इस छवि का परीक्षण नहीं कर सकता / सकती हूं, क्योंकि मैं उपलब्ध नहीं हूं - जैसा कि मेरा मित्र अनुपलब्ध है - यह छवि मेरे लिए लोड नहीं है। मैं नेक्सस 5 पर स्टॉक एंड्रॉइड (5.0.1) चला रहा हूं जो क्रोम का उपयोग ब्राउज़र के रूप में करता है।

http://41.media.tumblr.com/efebad51567e927b8f130f9bdc4efae3/tumblr_ndvnpjcBZa1qewacoo1_500.png

जब मैं छवि को सीधे लोड करने की कोशिश करता हूं तो मुझे 504 गेटवे टाइमआउट त्रुटि मिलती है।

संपादित करें: यह @JakeGould संदर्भ के लिए वास्तविक छवि पोस्ट कर रहा है।

आगे का परीक्षण और विवरण: मैं बाल्टीमोर एमडी में हूं, एलटीई डेटा से दूर चल रहा हूं और निम्नलिखित छवि ने काम किया: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

आगे के परीक्षण से पता चलता है कि पीएनजी समस्या नहीं है। मेरे द्वारा काम की गई अधिकांश अन्य छवियां png और jpg का मिश्रण थीं, लेकिन सभी गैर "41" सर्वर पर थीं।

अंतिम नोट: मुझे घर मिल गया है, मेरे wifi -Comcast पर hopping- मेरे फोन के साथ -इस डिवाइस पर मैं परीक्षण कर रहा हूं- और सभी तस्वीरें जो मैं 504 के कारण नहीं देख सका था, अब मैं देख सकता हूं।

संपादित करें: सुपरसुअर के लिए नया, छंटनी और संपादित पोस्ट इसलिए यह अधिक तथ्यात्मक और कम चर्चा थी।

अद्यतन करें: इश्यू एलटीई से बंधा हुआ लग रहा है। टम्बलर से भरा हुआ, कुछ ऐसी छवियां मिलीं जो लोड नहीं करेंगी, मेरे फोन को 3 जी के लिए मजबूर कर दिया, पृष्ठ को पुनः लोड किया, सभी छवियां दिखाती हैं। एलटीई पर वापस फोन लौटाया, कैश को मंजूरी दे दी, और जो छवियां पहले एलटीई के तहत लोड नहीं हुई थीं, अब लोड होती हैं।
(मैं फिर से परीक्षण कर रहा हूं और अब मैं पुन: पेश नहीं कर सकता। इसलिए शायद उपरोक्त व्यवहार एक लकीर था।)

Comments

यह अच्छी जानकारी है, लेकिन क्या मदद मिल सकती है यदि आप अपने भौतिक स्थान पर कुछ विवरण प्रदान कर सकते हैं। मैं ब्रुकलिन, एनवाई, यूएसए में काफी अच्छी तरह से जुड़ा हुआ चित्र देख सकता हूं। और मेरे सहूलियत के बिंदु से छवि को हाइविंड सीडीएन द्वारा वितरित किया जा रहा है।

— JakeGould