Chrome डिबगर में "समाधान: अनंतिम हेडर दिखाए गए हैं"

399

Google क्रोम इंस्पेक्टर ( F12) का उपयोग करके डाउनलोड किए गए संसाधनों को देखते समय मुझे एक अजीब चेतावनी संदेश दिखाई दिया :

सावधानी अनंतिम हेडर दिखाए जाते हैं

यहां छवि विवरण दर्ज करें

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

पहले प्रश्न के समान , मेरा संसाधन अवरुद्ध था, लेकिन बाद में स्वचालित रूप से उसी संसाधन को लोड किया गया। दूसरे प्रश्न के विपरीत , मैं कुछ भी ठीक नहीं करना चाहता; मैं जानना चाहता हूं कि इस संदेश का क्या मतलब है और मुझे यह क्यों मिला।

— साल्वाडोर डाली
स्रोत

3

यह समस्या तब भी दिखाई दे सकती है जब reuqest को डोमेन स्विचिंग के कारण नहीं भेजा जाता है जैसे कि www.domain.tld से डोमेन के लिए डेटा भेजना।

— आंद्रे बॉमिएर

@wvega इस SO प्रश्न में एक समान मुद्दा पोस्ट किया गया है, लेकिन इस प्रोविजनल हेडर्स सेंटेड इश्यू के लिए कोई संभावित स्पष्टीकरण नहीं लगता है । इसके लिए कोई ठोस उपाय? वास्तव में गुस्से वाला! मैंने यह प्रश्न कुछ समय पहले पोस्ट किया था।

— वेबब्लोवर

1

@webblover wvega द्वारा एक अच्छी व्याख्या है। और मैं वास्तव में एक समाधान की तलाश में नहीं था। मैं एक कारण को लेकर उत्सुक था।

— साल्वाडोर डाली

जब मैंने इसे बंद किया तो इससे मुझे मदद मिली:chrome://flags/#site-isolation-trial-opt-out

— Илья леленько

: मेरा उत्तर पढ़ें, यह के रूप में जटिल नहीं है के रूप में यह लग रहा है stackoverflow.com/questions/21177387/...

— csandreas1

353

संसाधन को एक एक्सटेंशन (मेरे मामले में AdBlock) द्वारा अवरुद्ध किया जा सकता है।

संदेश वहाँ है क्योंकि उस संसाधन को पुनः प्राप्त करने का अनुरोध कभी नहीं किया गया था, इसलिए जो हेडर दिखाए जा रहे हैं वे वास्तविक चीज़ नहीं हैं। जैसा कि आपने संदर्भित मुद्दे में समझाया है, सर्वर द्वारा प्रतिक्रिया देने पर वास्तविक हेडर अपडेट हो जाते हैं, लेकिन अनुरोध अवरुद्ध होने पर कोई प्रतिक्रिया नहीं होती है।

जिस तरह से मैंने अपने संसाधन को अवरुद्ध करने वाले विस्तार के बारे में पाया था वह क्रोम में नेट-इंटर्नल टूल के माध्यम से था:

क्रोम के नवीनतम संस्करणों के लिए

प्रकार chrome://net-export/एड्रेस बार में और एंटर करें।
रिकॉर्डिंग शुरू। और रिकॉर्डिंग फ़ाइल को स्थानीय में सहेजें।
वह पृष्ठ खोलें जो समस्याएँ दिखा रहा है।
नेट-इंटर्नल पर वापस जाएं
आप यहाँ रिकॉर्ड की गई लॉग फ़ाइल देख सकते हैं https://netlog-viewer.appspot.com/#import
घटनाओं पर क्लिक करें (###) और अपने संसाधन (URL के कुछ हिस्सों का उपयोग करें) से संबंधित ईवेंट को खोजने के लिए टेक्स्टफील्ड का उपयोग करें।
अंत में, ईवेंट पर क्लिक करें और देखें कि क्या दिखाई गई जानकारी आपको कुछ बताती है।

क्रोम के पुराने संस्करणों के लिए

प्रकार chrome://net-internalsएड्रेस बार में और एंटर करें।
वह पृष्ठ खोलें जो समस्याएँ दिखा रहा है।
नेट-इंटर्नल पर वापस जाएं, घटनाओं पर क्लिक करें (###) और अपने संसाधन से संबंधित इवेंट (URL के भागों का उपयोग करें) को खोजने के लिए टेक्स्टफील्ड का उपयोग करें।
अंत में, ईवेंट पर क्लिक करें और देखें कि क्या दिखाई गई जानकारी आपको कुछ बताती है।

— विलिंगटन वेगा
स्रोत

7

शाज़ का जवाब बेहतर है। आप इस संदेश को डिबगर में देखते हैं जब भी संसाधन को ब्राउज़र से कैश से पुनर्प्राप्त किया गया था बिना सर्वर से पूछे कि क्या सामग्री बदल गई है।

— मूर

4

मुझे लगता है कि दोनों उत्तर सही हैं, वे एक ही कहानी के दो पहलू बताते हैं। संदेश तब दिखाया जाता है जब कोई अनुरोध अवरुद्ध हो जाता है या संसाधन कैश से लोड होते हैं, लेकिन यह भी हर अनुरोध शुरू होने के बाद और जबकि ब्राउज़र सर्वर से प्रतिक्रिया की प्रतीक्षा कर रहा है। जैसे ही प्रतिक्रिया आती है, संदेश चला जाता है और वास्तविक हेडर दिखाए जाते हैं।

— विलिंगटन वेगा

2

यदि मुख्य रूप से विश्लेषण किया गया पृष्ठ पुनर्निर्देशित है, उदाहरण के लिए.com/.com/ -> 301-> example.com/b, और लक्ष्य पृष्ठ 200 के साथ उत्तर देता है, और फिर आप हेडर डेटा देखने के लिए एक निरीक्षक को लक्ष्य पृष्ठ / b में क्लिक करते हैं , आप उन्हें प्राप्त करेंगे, "अनंतिम हेडर दिखाए गए हैं" के साथ लेबल किया गया है। यह सही है, क्योंकि, आपने सीधे लक्ष्य पृष्ठ का विश्लेषण नहीं किया है। यदि आप ऐसा करते हैं, तो आपको लेबल के बिना हेडर डेटा मिलता है।

— एवगेनी

1

मैं यह निर्धारित करने में सक्षम था कि यह मेरी समस्या थी क्योंकि जब मैंने ऊपर किया था। मेरी https साइट एक https css फ़ाइल कह रही थी जो एक http पृष्ठ पर 302 रीडायरेक्ट कर रही थी। सुरक्षा फ़ाइल को लोड नहीं होने देगी और केवल अनंतिम हेडर दिखाएगी।

— स्टेरोप्स 19

1

ऐसा होने के कई कारणों की बहुत अच्छी व्याख्या है: stackoverflow.com/questions/12009423/…

— बोल्डनिक

112

मेरा मानना है कि ऐसा तब होता है जब वास्तविक अनुरोध नहीं भेजा जाता है। आमतौर पर तब होता है जब आप कैश्ड संसाधन लोड कर रहे होते हैं।

— Shazz
स्रोत

61

नहीं, 304 सशर्त अनुरोध के जवाब में सर्वर से संशोधित नहीं होता है। यदि आप एक कैश किए गए संसाधन को लोड कर रहे हैं और आपके ब्राउज़र को सर्वर से संपर्क करने की आवश्यकता नहीं है, तो आपको 304 नहीं संशोधित या किसी भी HTTP स्थिति को पूरा नहीं करना होगा क्योंकि HTTP अनुरोध नहीं किया जाएगा।

— थोमसट्रेटर

7

मेरे लिए यह काम करता है, जब मैंने डिबगर पैनल में "प्रोविजनल हेडर दिखाए गए हैं", अनुरोध का स्टेटस कोड "200 ओके (कैश से)" था

— रिची

3

मैंने इसे एक सेवा कार्यकर्ता की प्रतिक्रिया के साथ देखा, इसलिए मुझे लगता है कि कम से कम कुछ मामलों में, आप कैश प्रतिक्रिया के बारे में सही हैं :)

— जेकोबॉलनवुड

4

मैं देव उपकरण में कैश बंद कर देता हूं और फिर भी यह संदेश मिलता है। सभी फ़ाइलों के लिए स्थिति 200 है, नहीं "(कैश से)"। तो यह कभी-कभी कैश के कारण हो सकता है, लेकिन निश्चित रूप से हमेशा नहीं।

— राल्फ

यह मेरे मामले में कैश से डेटा लोड कर रहा है।

— अवीव लो

40

क्रोम v72 + के लिए यह मेरे लिए क्या हल किया गया था केवल यह था:

पर जाएं chrome://flags/और इस 3 झंडे को अक्षम करें

साइट अलगाव अक्षम करें
नेटवर्क सेवा सक्षम करें
नेटवर्क सेवा-प्रक्रिया चलाता है

या आप इसे कमांड लाइन से कर सकते हैं:

chrome --disable-site-isolation-trials --disable-features=NetworkService,NetworkServiceInProcess

ऐसा क्यों होता है?

ऐसा लगता है कि Google अपने क्रोमियम इंजन को मॉड्यूलर संरचना में बदल रहा है, जहां विभिन्न सेवाओं को स्टैंड-अलोन मॉड्यूल और प्रक्रियाओं में अलग किया जाएगा। वे इस प्रक्रिया को सर्विसिफ़िकेशन कहते हैं। नेटवर्क सेवा पहला कदम है, यूआई सेवा, पहचान सेवा और डिवाइस सेवा आ रही है। Google क्रोमियम प्रोजेक्ट साइट पर आधिकारिक जानकारी प्रदान करता है ।

क्या इसे बदलना खतरनाक है?

एक उदाहरण नेटवर्किंग है: एक बार हमारे पास एक नेटवर्क सेवा होती है जिसे हम बेहतर स्थिरता / सुरक्षा के लिए प्रक्रिया से बाहर चलाने के लिए चुन सकते हैं, या यदि हम संसाधन की कमी के कारण प्रक्रिया में हैं । स्रोत

— बद्र एल्मर
स्रोत

4

मैं इसे केवल "नेटवर्क सेवा सक्षम करें" और "नेटवर्क सेवा चलाने की प्रक्रिया में" प्राप्त करने में सक्षम था।

— स्मालोन

मैंने बस साइट अलगाव को निष्क्रिय कर दिया और मेरे लिए काम किया।

— आश्रित

3

इसने नियमित क्रोम (v74) में काम किया, हालांकि क्रोम कैनरी (v76) के नवीनतम संस्करण में अब "# नेटवर्क-सेवा" ध्वज गायब है ... कैनरी में इसके बिना काम करने के लिए इसे प्राप्त नहीं किया जा सकता है।

— अमीर

मैंने इस मुद्दे को दोनों ( localhost:8080और google.com!) पर देखा। साइट अलगाव को अक्षम करने के लिए google.com तय किया गया, लेकिन लोकलहोस्ट नहीं। केवल अन्य दो विकल्पों को अक्षम करना सभी मामलों के लिए इसे निर्धारित करता है।

— ब्लूराजा - डैनी पफ्लुगुफ्ट

मुझे केवल इसे बंद करना था: क्रोम: // झंडे / # साइट-अलगाव-परीक्षण-ऑप्ट-आउट

— Илья ьеленько

25

मुझे इस मुद्दे का सामना करना पड़ा, और मैं एक विशिष्ट कारण की पहचान करने में कामयाब रहा, जिसका उत्तर या प्रश्न में ऊपर उल्लेख नहीं किया गया है।

मैं SSL पर एक पूर्ण js स्टैक, कोणीय सामने का छोर और नोड बैक एंड चला रहा हूं, और API एक अलग डोमेन पर चल रहा है, जो पोर्ट 8081 पर चल रहा है, इसलिए मैं CORS अनुरोध और withCredentials कर रहा हूं क्योंकि मैं एपीआई से एक सत्र कुकी छोड़ रहा हूं।

इसलिए विशेष रूप से मेरा परिदृश्य था: POST अनुरोध, 8081 पोर्ट के साथ क्रेडेंशियल के कारण निरीक्षक में "चेतावनी: अनंतिम हेडर दिखाए गए हैं" संदेश और निश्चित रूप से सभी अनुरोधों को एक साथ अवरुद्ध कर दिया।

मेरा समाधान 443 के सामान्य एसएसएल पोर्ट से 8081 के नोड एसएसएल पोर्ट से अनुरोध पारित करने के लिए अपाचे को स्थापित करने के लिए था (नोड को उच्च पोर्ट पर होना चाहिए क्योंकि यह उत्पादों में रूट के रूप में नहीं चलाया जा सकता है)। इसलिए मुझे लगता है कि Chrome को SSL अपरंपरागत SSL पोर्ट के लिए अनुरोध पसंद नहीं है, लेकिन शायद उनका त्रुटि संदेश अधिक विशिष्ट हो सकता है।

— मिस्टर पी
स्रोत

2

यह ब्राउज़र की समान मूल नीति है - आपका वेबपृष्ठ और आपके द्वारा पढ़ा जा रहा संसाधन समान पोर्ट पर होना चाहिए। developer.mozilla.org/en-US/docs/Web/Security/…

— r3m0t

1

मदद के लिए बहुत धन्यवाद। मैं वेबपैक देव सर्वर का उपयोग कर रहा हूं और मैं सिर्फ एक पुनर्लेखन नियम जोड़ने में सक्षम था। '/graphql': { target: 'http://10.10.1.38:4000', changeOrigin: true }

— जेम्स हैरिंगटन

इसी तरह, मैंने क्रिएट-रिएक्शन-ऐप प्रोजेक्ट में "proxy": "http://192.168.98.110:1234"अपने साथ जोड़कर इस समस्या को हल किया package.json। उत्तर के विपरीत, मैं देव में कहीं भी HTTPS का उपयोग नहीं कर रहा हूं, लेकिन इसकी आवश्यकता थी क्योंकि मेरा ऐप और एपीआई अलग-अलग आईपी पर हैं।

— चिशीस्टैंडैंड

16

साइट अलगाव नामक एक नई सुविधा के कारण यह (केवल क्रॉस-मूल अनुरोधों के लिए) हो सकता है

यह पृष्ठ समस्या और कार्य-विवरण के बारे में बताता है । जिसे chrome://flags/#site-isolation-trial-opt-outक्रोम में जाना है और उस सेटिंग को "ऑप्ट-आउट" में बदलना है और क्रोम को फिर से लोड करना है।

यह एक ज्ञात मुद्दा है । हालाँकि, यह पेज कहता है कि यह क्रोम 68 में तय है, लेकिन मैं क्रोम 68 चला रहा हूं और मेरे पास अभी भी मुद्दा है।

— onlynone
स्रोत

1

यदि आपके अनुरोध ब्लॉक नहीं किए गए हैं (200 ठीक है), तो यह केवल कोर अनुरोधों के साथ होता है, और लापता हेडर कुकी है , आप इस उत्तर की जांच करना चाहते हैं। धन्यवाद, @onlynone

— semako

@ सेमाको, क्या आप इसे थोड़ा और विस्तार से बता सकते हैं? मैं एक समान समस्या का सामना कर रहा हूं, लेकिन मुझे पूरी तरह से समझ में नहीं आता है कि क्यों। अधिक जानकारी के लिए, कृपया मेरी सबसे हाल की पोस्ट देखें। धन्यवाद।

— adn bps

12

HTTP / 2 पुश किए गए संसाधनProvisional headers are shown निरीक्षक में उसी सिद्धांत के लिए उत्पादन करेंगे, जैसा @wvega ने अपने उत्तर में पोस्ट किया है ।

उदाहरण: चूंकि सर्वर ने क्लाइंट को संसाधन (ओं) को धकेल दिया ( ग्राहक द्वारा उनसे अनुरोध करने से पहले ), ब्राउज़र में संसाधन कैश हैं और इसलिए ग्राहक कभी अनुरोध नहीं करता / करती है; इसलिए क्योंकि...

... सर्वर द्वारा प्रतिक्रिया देने पर वास्तविक हेडर अपडेट किए जाते हैं, लेकिन अनुरोध अवरुद्ध होने पर कोई प्रतिक्रिया नहीं होती है।

— समुदाय
स्रोत

12

मेरी स्थिति क्रॉस-ऑरिजिन से संबंधित है।
स्थिति: ब्राउज़र OPTIONSवास्तविक अनुरोध भेजने से पहले अनुरोध भेजता है जैसे GETया POST। बैकएंड डेवलपर OPTIONSअनुरोध से निपटने के लिए भूल जाता है , यह सेवा कोड के माध्यम से जाने देता है, जिससे प्रसंस्करण समय बहुत लंबा हो जाता है। axiosआरंभीकरण में मैंने जो टाइमआउट सेटिंग लिखी थी, उससे भी लंबी , जो कि 5000 मिलीसेकंड है। इसलिए, वास्तविक अनुरोध नहीं भेजा जा सका, और फिर मुझे provisional headers are shownसमस्या का सामना करना पड़ा ।
समाधान: जब OPTIONSअनुरोध करने की बात आती है , तो एपीआई सिर्फ रिटर्न परिणाम का समर्थन करता है, यह अनुरोध को तेज करता है और वास्तविक अनुरोध को समय से पहले भेजा जा सकता है।

— Alexee
स्रोत

6

मुझे संदेह है कि मेरा उत्तर आपकी मदद करने के लिए समय पर है, लेकिन अन्य इसे मददगार लग सकते हैं। मैंने jQuery Ajax पोस्ट स्क्रिप्ट के साथ एक समान समस्या का अनुभव किया जो मैंने बनाया था।

यह पता चला कि मेरे पास पोस्ट को फायर करने के लिए उपयोग किए जा रहे A टैग के href विशेषता में एक टाइपो था। मैंने href = " javacsript : " टाइप किया था । ('s' और 'c' को उलटते हुए) .. इससे स्क्रिप्ट को पृष्ठ को रीफ़्रेश करने का प्रयास करना पड़ा, जबकि पोस्ट आग लगाने का प्रयास कर रही थी। टाइपो को ठीक किया और यह मेरे लिए बिल्कुल ठीक काम किया।

— बर्बर
स्रोत

उसी तरह के मुद्दे पर भाग गया, कोई टाइपो नहीं था लेकिन मेरे पास एक स्क्रिप्ट थी जो पृष्ठ को पोस्ट करने से पहले लोड हो रही थी / पूरी हो गई थी।

— रेनडेल

4

यह संदेश तब हो सकता है जब वेबसाइट HSTS का उपयोग करके सुरक्षित हो । फिर, जब कोई URL के HTTP संस्करण से लिंक करता है, तो ब्राउज़र, जैसा कि HSTS द्वारा निर्देश दिया गया है, एक HTTP अनुरोध जारी नहीं करता है, लेकिन HTTPS संसाधन को आंतरिक रूप से पुनर्निर्देशित करता है। यह HTTPS डाउनग्रेड हमलों जैसे sslstrip से बचने के लिए है ।

— dionyziz
स्रोत

मैंने एचएसटीएस को निष्क्रिय कर दिया और मूल हेडर फिर से दिखाई दिए। धन्यवाद!

— kenberkeley

3

ऐसा इसलिए हो सकता है क्योंकि आपने एक अजाक्स अनुरोध भेजा था, उसी समय आप अपने पृष्ठ को किसी अन्य स्थान पर किसी अन्य स्थान पर भेज दें। इसलिए पिछला अनुरोध विफल हो गया।

— Frankjs
स्रोत

2

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

मेरे मामले में सर्वर को अनुरोध सही ढंग से भेजा गया था, सर्वर-साइड कोड ने फिर एक त्रुटि उत्पन्न की और मेरे कस्टम त्रुटि हैंडलिंग ने HTTP स्थिति संदेश क्षेत्र में त्रुटि संदेश लौटा दिया। लेकिन त्रुटि संदेश (यहाँ वर्णित http://aspnetwebstack.codeplex.com/workitem/1386 ) में अमान्य वर्णों के कारण क्लाइंट त्रुटि पर यह त्रुटि प्राप्त नहीं हुई, जिसके परिणामस्वरूप दूषित प्रतिक्रिया शीर्षलेख प्राप्त हुए।

— फ्लोरियन हैदर
स्रोत

2

मैं इस मुद्दे में एक AJAX कॉल के साथ भाग गया जो कभी पूरा नहीं होगा। मैंने wvega की सलाह का पालन किया और chrome://net-internalsअंत में दूसरे को निर्धारित करने के लिए डिबगिंग के बारे में टिप दीclick पृष्ठ में ईवेंट हैंडलर , मूल नोड पर सुनना, ब्राउज़र को उसी URL पर नेविगेट करने का कारण बना रहा था (इसलिए यह आसानी से ध्यान देने योग्य नहीं था)।

समाधान जोड़ने के लिए था event.stopPropagation()एक में clickफार्म पर हैंडलर डोम खलबली मचाने वाले और प्रगति में AJAX अनुरोध (एक के माध्यम से शुरू की रद्द करने से क्लिक रखने के लिए सबमिट बटन submitहैंडलर पर form)।

— सुगठित
स्रोत

2

मैंने इसे हाल ही में (आज वास्तव में) उठाया है, जहां मैंने एक AJAX कॉल सर्वर के लिए किया है और क्रोम "सावधानी: अनंतिम हेडर दिखाए गए हैं।" सर्वर साइड PHP स्क्रिप्टिंग में, MySQL क्वेरीज हैं जो बहुत ज्यादा इंस्टेंट हो सकती हैं या दिए गए परिदृश्य के आधार पर कुछ सेकंड ले सकती हैं। जब तक क्वेरीज़ पूरी नहीं हो जाती, तब तक मेरे सर्वर की प्रतिक्रिया ब्राउज़र में वापस नहीं भेजी जाती है। मैंने पाया है कि मुझे यह त्रुटि केवल तब आती है जब समय लेने वाले (कुछ सेकंड तक कुल) किए जा रहे हैं और प्रतिक्रिया को वापस भेजे जाने से रोकते हैं।

मेरे परिदृश्य में मौसम मॉडल आउटपुट के लिए सैकड़ों स्तंभों को जोड़कर / हटाकर तालिका को बदलने की बहुत कम संभावना है ... इसलिए प्रतिक्रिया तालिका प्रश्नों के एक लूप के माध्यम से पुनरावृत्ति करने से पीछे रह जाती है।

— Gwi7d31
स्रोत

पीएचपी वर्कर्स शायद आपके लिए कुछ हों

— बार्टोलोमिएज ज़ेलेवस्की

2

ऐसा होने का एक सामान्य कारण यह है कि यदि आप किसी ईवेंट को ट्रैक कर रहे हैं और आप डिफ़ॉल्ट कार्रवाई को रोक नहीं पाते हैं। उदाहरण के लिए, यदि आपके पास एक क्लिक ईवेंट है, तो आप इसे शामिल करना चाहेंगे:

e.preventDefault();

या

return false;

यदि आप नहीं करते हैं, तो आप अनंतिम हेडर को चेतावनी के साथ-साथ अपने वेब कंसोल के नेटवर्क टैब में "रद्द" स्थिति देखेंगे।

— bigtex777
स्रोत

2

मेरे मामले में यह एक संसाधन (svg / img) के लिए सिर्फ एक झूठा सेट रास्ता था

— typocoder
स्रोत

हां - मेरे लिए, अनुरोध के लिए फ़ाइल इनपुट का उपयोग करते समय अनुमतियाँ गायब हैं।

— दर्शन २

2

यह समस्या मुझे तब हुई जब मैं एक अवैध HTTP प्राधिकरण शीर्ष लेख भेज रहा था। मैं base64 के लिए भूल गया यह सांकेतिक शब्दों में बदलना।

— रॉबर्ट क्रिस्टोफर
स्रोत

1

मेरा मामला प्राधिकरण का शीर्षक बहुत लंबा था

— एगोरिला

1

मुझे यह पता चला और यह तब चला गया जब मैंने https से http पर स्विच किया। SSL सेर्ट्स जो हम dev में उपयोग करते हैं, वे 3rd पार्टी द्वारा सत्यापित नहीं होते हैं। वे अभी-अभी स्थानीय रूप से देव सेर उत्पन्न हुए हैं।

क्रोम कैनरी और फ़ायरफ़ॉक्स में समान कॉल ठीक काम करते हैं। Chrome के रूप में ये ब्राउज़र SSL प्रमाणपत्र के बारे में उतने सख्त नहीं दिखते हैं। Chrome में "चेतावनी: अनंतिम हेडर ..." संदेश के साथ कॉल विफल हो जाएगी।

मुझे लगता है कि जब हम मंच और ठेस में एक वैध एसएसएल प्रमाणपत्र का उपयोग करते हैं, तो हम आशा करते हैं कि हम इस व्यवहार को क्रोम में नहीं देखेंगे।

— कोडवॉरिअर
स्रोत

मैंने कर्ल करने की कोशिश की, और 60 प्राप्त किया। इस उत्तर से एसएसएल इंस्टॉलेशन में लापता श्रृंखला का पता लगाएं। श्रृंखला जोड़ें और समस्या चली गई। धन्यवाद दोस्त! कृपया इसे जांचने के लिए उपयोग करें: curl -s -D- https: // <yourcomain.com>

— apis17

1

बस अपने दो सेंट में फेंक रहा हूं। मैं एक वेब अनुप्रयोग लिख रहा हूं जो कॉर्स अनुरोधों और एक पूर्ण विश्वसनीय वेब सेवा का उपयोग कर रहा है। मैंने पाया है कि जब मेरे पास कोई अपवाद या PHP त्रुटि है, तो क्रोम इस त्रुटि को फेंक देगा। बस किसी और को समस्या में चला जाता है। मैंने पाया कि जब ऐसा होता है तो मैं क्रोम ऐप "पोस्टमैन - रेस्ट क्लाइंट" को फायर कर सकता हूं और ठीक उसी अनुरोध को चला सकता हूं, लेकिन क्रोम ऐप में मुझे वास्तव में इस गैर-वर्णनात्मक त्रुटि के बजाय PHP एरर थॉट्स मिलेंगे।

— JDubDev
स्रोत

1

जब मैं त्रुटि के परिणामस्वरूप परिवर्तन करता हूं, तो मैंने दूसरी बार js की आवश्यकता के लिए main.js लोड करने का प्रयास करने पर इस समस्या को चलाया। मैं सिर्फ डेवलपर टूल सेटिंग्स "कैश अक्षम करें (जब DevTools खुला है)" पर चालू हुआ। और यह आकर्षण था।

— ओहद सदन
स्रोत

बस एक ऐसा ही मुद्दा था जहां क्रोम देव उपकरण खुले रहने पर html5 वीडियो लोड नहीं होगा क्योंकि मैं 'अक्षम करें कैश (जबकि DevTools खुला है)' सक्षम है। सेटिंग को अक्षम करने से समस्या हल हो गई।

— एंथ 12

1

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

— इरेज़ कोहेन
स्रोत

1

यह मेरे लिए हो रहा था, जब मेरे पास एक डाउनलोड लिंक था और उस पर क्लिक करने के बाद मैं यह भी कोशिश कर रहा था कि क्लिक को jquery के साथ पकड़ा जाए और एक अजाक्स अनुरोध भेजें। समस्या इसलिए थी क्योंकि जब आप डाउनलोड लिंक पर क्लिक कर रहे हैं, तो आप पृष्ठ छोड़ रहे हैं, यहां तक कि ऐसा नहीं दिखता है। यदि कोई फ़ाइल स्थानांतरण नहीं होता है, तो आप अनुरोधित पृष्ठ देखेंगे .. इसलिए मैंने इस समस्या को रोकने के लिए एक लक्ष्य = "_ blank" सेट किया।

— हयक अगहबयकन
स्रोत

1

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

मेरे मामले में समाधान window.print ();स्क्रिप्ट को हटाने के लिए था जिसे वह <body>पॉपअप विंडो पर प्रिंट संवाद को रोकने के लिए निष्पादित कर रहा था ।

— अरनू गलोफ्रे
स्रोत

1

मैंने इसे तब देखा जब मेरे सर्वर से कनेक्शन की संख्या क्रोम की अधिकतम-कनेक्शन-प्रति-सर्वर सीमा 6 से अधिक हो गई।

— mab
स्रोत

1

अपने कोड के इस कोड का उपयोग करें:

header('Cache-Control: no-cache, no-store, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');

यह मेरे लिए काम करता है।

— नबी काज
स्रोत

0

यहाँ एक और उपाय है।

यदि आप $ ajax () कॉल के साथ इस समस्या का सामना करते हैं, तो http://इससे पहले कि आपके सर्वरहोस्ट आपकी समस्या को हल करेंगे।

var requestURL = "http://" + serverHost;
$.ajax({
    dataType: "json",
    url: requestURL,
    data: data,
    success: success    
});

— KTU
स्रोत

0

यदि आप एक Asp.Net Mvc एप्लिकेशन विकसित कर रहे हैं और आप JsonResultअपने कंट्रोलर में लौटने की कोशिश कर रहे हैं , तो सुनिश्चित करें कि आप JsonRequestBehavior.AllowGetइस Jsonविधि में जोड़ें । उसने मेरे लिए इसे हल कर दिया।

public JsonResult GetTaskSubCategories(int id)
{
    var subcategs = FindSubCategories(id);

    return Json(subcategs, JsonRequestBehavior.AllowGet);  //<-- Notice it has two parameters
}

— codingbiz
स्रोत

0

"सावधानी: अनंतिम हेडर दिखाए जाते हैं" संदेश तब दिखाया जा सकता है जब वेबसाइट HTTPS पर होस्ट की गई वेबसाइट HTTP पर होस्ट किए गए WebApi को कॉल करती है। आप सभी की जाँच कर सकते हैं यदि आपके सभी एपी HTTPS हैं। संसाधन को असुरक्षित करने के लिए ब्राउज़र कॉल करने से रोकता है। जब आप HTTP के साथ डोमेन के लिए FETCH API का उपयोग करते हैं तो आप अपने कोड में समान संदेश देख सकते हैं।

मिश्रित सामग्री: ' https://website.com ' पेज HTTPS से अधिक भरा हुआ था, लेकिन एक असुरक्षित संसाधन ' http://webapi.com ' का अनुरोध किया । इस अनुरोध को अवरुद्ध कर दिया गया है; सामग्री को HTTPS पर परोसा जाना चाहिए।

— रफाल साइपर
स्रोत

0

मेरे पास मेरे MEAN ऐप के साथ भी ऐसा ही मुद्दा था। मेरे मामले में, यह मुद्दा केवल एक अनुरोध में हो रहा था। मैंने एडब्लॉक हटाने की कोशिश की, कैशे क्लियर करने की कोशिश की और विभिन्न ब्राउज़रों के साथ कोशिश की। कुछ भी मदद नहीं की।

अंत में, मुझे पता चला है कि एपीआई एक विशाल JSON ऑब्जेक्ट को वापस करने की कोशिश कर रहा था। जब मैंने एक छोटी सी वस्तु भेजने की कोशिश की है, तो यह ठीक काम कर रहा था। अंत में, मैंने JSON के बजाय बफर को वापस करने के लिए अपना कार्यान्वयन बदल दिया है।

मैं इस मामले में एक त्रुटि फेंकने के लिए एक्सप्रेसजेज की कामना करता हूं।

— चंद्रू
स्रोत

0

कुछ पैकेजों का उपयोग करते समय यह समस्या भी आएगी webpack-hot-middlewareऔर एक ही समय में कई पृष्ठ खोलें। webpack-hot-middlewareकोड के परिवर्तनों को सुनने के लिए प्रत्येक पृष्ठ के लिए फिर से ताज़ा करने के लिए एक कनेक्शन बनाएगा। प्रत्येक ब्राउज़र में एक max-connections-per-serverसीमा होती है जो क्रोम के लिए 6 है, इसलिए यदि आपने क्रोम में पहले से ही 6 से अधिक पृष्ठ खोले हैं, तो नए अनुरोध को तब तक लटका दिया जाएगा जब तक आप कुछ पृष्ठ बंद नहीं कर देते।

— LCB
स्रोत

0

मेरे मामले में कारण एडब्लॉक एक्सटेंशन था।

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

परिवर्तन को प्रभावी करने के लिए, देव उपकरणों को बंद करना और पृष्ठ को ताज़ा करना भी आवश्यक था

— Tarmo
स्रोत