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 तपाईंको एन्डपोइन्ट हो भनी पुष्टि गर्नुहोस्।
- पार्सर छुनुअघि प्रतिक्रिया वर्गीकरण गर्नुहोस्।
- रुटिङ, पहुँच, प्रतिनिधित्व वा सम्झौता सुधार्नुहोस्, र पार्सर खुकुलो बनाएर कहिल्यै होइन।