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 നിങ്ങളുടെ എൻഡ്‌പോയിന്റും ആണെന്ന് ഉറപ്പാക്കുക.
- പാഴ്സർ സ്പർശിക്കുന്നതിന് മുമ്പ് പ്രതികരണം വർഗ്ഗീകരിക്കുക.
- റൂട്ടിംഗ്, ആക്‌സസ്, പ്രാതിനിധ്യം, കരാർ എന്നിവ തിരുത്തുക, പാഴ്സർ അയച്ചുകൊടുത്ത് ഒരിക്കലുമല്ല.