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 તમારું એન્ડપોઇન્ટ છે.
- પાર્સરને સ્પર્શતાં પહેલાં પ્રતિસાદનું વર્ગીકરણ કરો.
- રૂટિંગ, ઍક્સેસ, રજૂઆત કે કરાર સુધારો, અને પાર્સર ઢીલો કરીને કદી નહીં.