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 तुमचा JavaScript कॉल करत असलेल्या URL शी तुलना करा. इतरत्र संपणारा रीडायरेक्ट, गहाळ किंवा जास्त अंतिम स्लॅश, पद्धतीची विसंगती, किंवा हललेल्या पृष्ठावरून सापेक्ष मार्गावर पाठवणारा फॉर्म शोधा. रीडायरेक्ट साखळी शेवटपर्यंत पाठपुरावा करा आणि पहिल्याऐवजी अंतिम 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 तुमचा एंडपॉइंट आहे याची खात्री करा.
- पार्सरला स्पर्श करण्यापूर्वी प्रतिसादाचे वर्गीकरण करा.
- मार्गदर्शन, प्रवेश, प्रतिनिधित्व किंवा करार दुरुस्त करा आणि पार्सर सैल करून कधीही नाही.