AJAX फ़ॉर्म को JSON चाहिए पर HTML मिलता है: प्रतिक्रिया को चरण-दर-चरण जाँचें
200 स्थिति JSON होने का प्रमाण नहीं है। नेटवर्क पैनल को चरण-दर-चरण देखें और परिवहन, निरूपण तथा अनुबंध की विफलताएँ अलग करें।
फ़ॉर्म भेजा जाता है, स्पिनर दिखता है, और कंसोल कहता है कि JSON में स्थान 0 पर अनपेक्षित चिह्न < है। पृष्ठ स्वयं ठीक से लोड होता है, इसलिए पहली प्रवृत्ति पार्सर या टनल को दोष देना होती है। सामान्यतः इनमें से कोई भी शामिल नहीं होता: भेजना पृष्ठ लोड से अलग अनुरोध है, और वह ऐसा कुछ लेकर लौटा है जो JSON नहीं है। उसी क्रम में काम करें जिसमें ब्राउज़र वास्तव में इसे उजागर करता है, क्योंकि चार संभावित उत्तरों के लिए चार अलग सुधार चाहिए।
चरण 1: वह भेजना पकड़ें जो वास्तव में हुआ
भेजने से पहले नेटवर्क पैनल खोलें, लॉग को नेविगेशन के पार प्रविष्टियाँ सुरक्षित रखने के लिए सेट करें, और फिर उस खाते पर एक हानिरहित परीक्षण भेजें जिसे उपयोग करने की अनुमति है। वह अनुरोध चुनें जो फ़ॉर्म ने स्वयं शुरू किया, पृष्ठ का दस्तावेज़ अनुरोध नहीं।
फ़िल्टर से सावधान रहें। XHR या Fetch फ़िल्टर सुविधाजनक है, पर यदि फ़्रेमवर्क अब भी छिपे iframe या गतिशील रूप से बने फ़ॉर्म से भेजता है, तो फ़िल्टर उस एकमात्र महत्वपूर्ण अनुरोध को छिपा देगा। पहले बिना फ़िल्टर एक बार भेजें और देखें क्या आया।
चुने गए अनुरोध के लिए कोई भी व्याख्या करने से पहले छह चीज़ें लिखें: विधि, क्वेरी स्ट्रिंग सहित पूरा URL, स्थिति, रीडायरेक्ट श्रृंखला, प्रतिक्रिया का Content-Type, और बॉडी की पहली पंक्तियाँ। Chrome DevTools का नेटवर्क पैनल संदर्भ Headers, Response और Initiator दृश्यों को कवर करता है जहाँ ये होते हैं, और अन्य ब्राउज़रों के समतुल्य पैनल वही फ़ील्ड दिखाते हैं।
चरण 2: पुष्टि करें कि यही वह अनुरोध है जो आप सोचते हैं
आश्चर्यजनक रूप से बहुत सी JSON त्रुटियाँ वास्तव में रूटिंग त्रुटियाँ हैं। यदि सबमिट हैंडलर preventDefault बुलाने से पहले अपवाद फेंकता है, तो ब्राउज़र action विशेषता में लिखे पते पर मूल फ़ॉर्म POST करता है, और सर्वर पूरा HTML पृष्ठ लौटाता है। हैंडलर कभी नहीं चलता, इसलिए JSON कभी माँगा ही नहीं गया।
पैनल के URL की तुलना उस URL से करें जिसे आपका JavaScript बुलाता है। कहीं और समाप्त होने वाला रीडायरेक्ट, गायब या अतिरिक्त अंतिम स्लैश, विधि का मेल न खाना जहाँ हैंडलर GET भेजता है और एंडपॉइंट POST स्वीकार करता है, या किसी स्थानांतरित पृष्ठ से सापेक्ष पथ पर भेजने वाला फ़ॉर्म खोजें। रीडायरेक्ट श्रृंखला को अंत तक देखें और अंतिम URL नोट करें, पहला नहीं।
फिर आरंभकर्ता जाँचें। यदि अनुरोध आपकी स्क्रिप्ट के बजाय दस्तावेज़ नेविगेशन से आया है, तो समस्या पहले ही मिल गई है, और प्रतिक्रिया पार्सर में कोई बदलाव मदद नहीं करेगा।
चरण 3: परिणाम को चार श्रेणियों में बाँटें
प्रत्येक परिणाम इनमें से ठीक एक में आता है, और श्रेणी तय करती है कि आगे कहाँ देखना है।
| What you see | Category | Where to look |
|---|---|---|
| Request never finishes, TLS or connection error | No usable response | Endpoint reachability, certificate, front-end timeout |
| Request completes, script gets an opaque failure | Access blocked | Cross-origin policy, credentials mode, missing response header |
| 200 with an HTML body or a login form | Wrong representation | Redirect, expired session, route fallback, error handler |
| Body begins with a notice then valid JSON | Wrong representation | Server-side warning output before serialisation |
| Valid JSON, framework rejects it | Contract mismatch | Envelope shape, field names, value types |
बीच की पंक्तियाँ वही हैं जिनका लोग गलत निदान करते हैं, क्योंकि स्थिति 200 है। रीडायरेक्ट के बाद मिलने वाला साइन-इन पृष्ठ पूरी तरह अच्छी HTTP प्रतिक्रिया और बहुत खराब JSON दस्तावेज़ है। application/json सामग्री प्रकार उसे ठीक नहीं करता: यह एक लेबल है, और गलत लेबल वाली बॉडी फिर भी पार्स नहीं होती। पहुँच अवरुद्ध वह पंक्ति है जो पूर्ण अनुरोध जैसी दिखती है: पैनल स्थिति दिखाता है, पर क्रॉस-ओरिजिन नीति बॉडी रोक लेती है, इसलिए बुलाने वाली स्क्रिप्ट के लिए वह समय-सीमा जितनी ही बेकार है।
चौथी पंक्ति पुराने PHP और फ़्रेमवर्क ढेर पर उतनी ही सामान्य है। एन्कोडेड पेलोड से पहले छपी अप्रचलन चेतावनी ऐसी बॉडी बनाती है जिसे कोई JSON पार्सर स्वीकार नहीं करेगा, और अक्सर वही चेतावनी पूरी व्याख्या होती है।
चरण 4: पार्सर की त्रुटि को शब्दशः पढ़ें
त्रुटि पाठ उस पहले अक्षर का नाम लेता है जिसने पार्स तोड़ा, और यह प्रायः बिना किसी अनुमान के श्रेणी पहचान देता है।
| Error text (Chrome/V8) | What it means |
|---|---|
| Unexpected token < in JSON at position 0 | The body starts with markup: an HTML page or an error document |
| Unexpected end of JSON input | Empty body, or the response was truncated |
| Unexpected token o in JSON at position 1 | You parsed something already parsed, typically an object rather than text |
| Unexpected token u | The body starts with the bare word undefined, usually an empty response rendered as a string |
200 के साथ खाली बॉडी अपने आप में एक मामला है: एंडपॉइंट चला, कुछ पैदा नहीं किया, और नीचे किसी चीज़ ने उसे सफलता मान लिया। यह परिवहन नहीं बल्कि अनुप्रयोग अनुबंध की विफलता है, और इसका स्थान प्रॉक्सी में नहीं अगले चरण में है। Firefox और Safari वही चार विफलताएँ अलग ढंग से लिखते हैं, इसलिए सटीक स्ट्रिंग के बजाय अक्षर या खाली बॉडी पर मिलाएँ।
चरण 5: उस परत को ठीक करें जिसकी ओर साक्ष्य इशारा करते हैं
रूटिंग समस्या के लिए अनुरोध ठीक करें: action सुधारें, हैंडलर को गिरने से रोकें, एंडपॉइंट और विधि मिलाएँ, और फिर परीक्षण करें। निरूपण समस्या के लिए जिसने बॉडी बनाई उसे ठीक करें, और पता लगाएँ कि जहाँ डेटा अपेक्षित था वहाँ त्रुटि दस्तावेज़ क्यों लौटता है। अनुबंध समस्या के लिए जिस संस्करण को आप चला रहे हैं उसके लिए फ़्रेमवर्क की वास्तविक अपेक्षित संरचना पढ़ें, और क्लाइंट को ढीला करने के बजाय प्रतिक्रिया को उसी के अनुसार ढालें।
पहुँच अवरुद्ध प्रतिक्रिया को अपना अलग दौर चाहिए, क्योंकि अनुरोध स्वयं सही हो सकता है और बॉडी कभी आपके कोड तक न पहुँचे। प्रतिक्रिया के Access-Control-Allow-Origin की तुलना ब्राउज़र द्वारा भेजे गए सटीक Origin से करें, और याद रखें कि वाइल्डकार्ड क्रेडेंशियल वाला अनुरोध पूरा नहीं करता। क्लाइंट पर credentials: 'include' को सर्वर पर Access-Control-Allow-Credentials: true के साथ जोड़ें, और देखें कि कॉल ने no-cors मोड इस्तेमाल किया या नहीं, जहाँ अपारदर्शी बॉडी दोष नहीं बल्कि प्रलेखित परिणाम है।
पार्सर को अधिक उदार चीज़ से बदलना वह एकमात्र सुधार है जिससे बचना चाहिए। प्रतिक्रिया को कोड के रूप में मूल्यांकित करना, या पार्स होने तक पाठ छीलना, अनुबंध की असंगति छिपाता है और मौन के बदले इंजेक्शन की सतह जोड़ता है। इसी तरह स्थिति को बॉडी से अलग जाँचना आवश्यक है: अनुप्रयोग-स्तरीय त्रुटि ऑब्जेक्ट वाला 200 कई API में सामान्य है और पेलोड पढ़कर संभालना चाहिए।
जब किसी और की मदद चाहिए, तो कच्चे निर्यात के बजाय न्यूनतम रिकॉर्ड साझा करें — विधि, URL, स्थिति, रीडायरेक्ट के बाद अंतिम URL, प्रतिक्रिया का सामग्री प्रकार, बॉडी का आकार और अपेक्षित अनुबंध। नेटवर्क अभिलेखों में कुकीज़, टोकन, क्वेरी स्ट्रिंग और फ़ॉर्म में मौजूद व्यक्तिगत डेटा होता है, और स्वचालित सैनिटाइज़र समीक्षा नहीं है।
- कोई भी कोड बदलने से पहले बिना फ़िल्टर अनुरोध पकड़ें।
- पुष्टि करें कि आरंभकर्ता आपकी स्क्रिप्ट थी और अंतिम URL आपका एंडपॉइंट है।
- पार्सर छूने से पहले प्रतिक्रिया का वर्गीकरण करें।
- रूटिंग, पहुँच, निरूपण या अनुबंध ठीक करें, और पार्सर ढीला करके कभी नहीं।