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 మీ ఎండ్‌పాయింట్ అని నిర్ధారించండి.
- పార్సర్‌ను తాకే ముందు ప్రతిస్పందనను వర్గీకరించండి.
- రూటింగ్, యాక్సెస్, ప్రాతినిధ్యం లేదా ఒప్పందాన్ని సరిచేయండి, పార్సర్‌ను సడలించి ఎప్పుడూ కాదు.