Ang form na AJAX ay umaasa sa JSON ngunit tumatanggap ng HTML: sundan ang tugon hakbang-hakbang
Ang 200 na tugon ay hindi patunay na JSON ito. Siyasatin ang panel ng Network hakbang-hakbang at ihiwalay ang mga kabiguan sa transportasyon, presentasyon at kontrata.
Naipapadala ang form, lumalabas ang umiikot na sagisag, at sinasabi ng console na may hindi inaasahang token < sa JSON sa posisyon 0. Maayos na naglo-load ang pahina mismo, kaya ang unang hilig ay sisihin ang parser o ang tunel. Karaniwang wala sa dalawa ang sangkot: ang pagpapadala ay ibang kahilingan kaysa paglo-load ng pahina, at bumalik ito na may isang bagay na hindi JSON. Magtrabaho sa pagkakasunod-sunod na aktuwal na ibinubunyag ito ng browser, dahil ang apat na posibleng sagot ay nangangailangan ng apat na magkakaibang pagwawasto.
Hakbang 1: huwag mahuli ang pagpapadalang talagang nangyari
Buksan ang panel ng Network bago magpadala, itakda ang log na panatilihin ang mga entry sa pagitan ng mga nabigasyon, at pagkatapos ay gumawa ng isang hindi nakapipinsalang pagsubok na pagpapadala sa account na pinapayagan kang gamitin. Piliin ang kahilingang sinimulan ng form mismo, hindi ang kahilingan ng dokumento ng pahina.
Mag-ingat sa mga filter. Maginhawa ang filter ng XHR o Fetch, ngunit kung nagpapadala pa rin ang balangkas sa pamamagitan ng nakatagong iframe o form na ginawa nang dinamiko, itatago ng filter ang tanging mahalagang kahilingan. Magpadala muna nang isang beses nang walang filter at tingnan kung ano ang lumitaw.
Para sa piniling kahilingan, isulat ang anim na bagay bago ang anumang interpretasyon: ang paraan, ang buong URL kasama ang query string, ang katayuan, ang kadena ng pag-redirect, ang Content-Type ng tugon, at ang mga unang linya ng katawan. Sinasaklaw ng sanggunian ng panel ng Network ng Chrome DevTools ang mga view na Headers, Response at Initiator kung saan naroon ang mga ito, at ang katumbas na mga panel sa ibang browser ay nagpapakita ng parehong mga field.
Hakbang 2: tiyakin na ito ang kahilingang iniisip mo
Nakakagulat na marami sa mga error sa JSON ay talagang error sa routing. Kung ang handler ng pagpapadala ay nagtatapon ng exception bago tawagin ang preventDefault, gumagawa ang browser ng native na POST ng form patungo sa address na sinasabi ng action attribute, at sumasagot ang server ng buong pahinang HTML. Hindi kailanman tumatakbo ang handler, kaya hindi kailanman hiniling ang JSON.
Ihambing ang URL sa panel sa URL na tinatawag ng iyong JavaScript. Hanapin ang redirect na nagtatapos sa ibang lugar, kulang o sobrang trailing slash, hindi pagtutugma ng paraan, o form na nagpapadala sa isang relatibong landas mula sa pahinang lumipat. Sundan ang kadena ng redirect hanggang sa dulo at itala ang huling URL, hindi ang una.
Pagkatapos ay suriin ang nagpasimula. Kung ang kahilingan ay nagmula sa nabigasyon ng dokumento at hindi sa iyong script, natagpuan mo na ang problema, at walang pagbabago sa parser ng tugon ang makakatulong.
Hakbang 3: uriin ang resulta sa apat na kategorya
Ang bawat resulta ay kabilang sa eksaktong isa sa mga ito, at ang kategorya ang magpapasya kung saan titingin sa susunod.
| 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 |
Ang mga gitnang hanay ang madalas na maling masuri, dahil ang katayuan ay 200. Ang pahina ng pag-sign in na naabot pagkatapos ng redirect ay isang ganap na mabuting tugon ng HTTP at isang napakasamang dokumentong JSON. Hindi ito inaayos ng uri ng nilalaman na application/json: ito ay isang label lamang, at ang maling label na katawan ay hindi pa rin ma-parse. Ang Na-block ang access ay ang hanay na mukhang tapos na kahilingan: nagpapakita ng katayuan ang panel, ngunit pinipigilan ng patakaran ng cross-origin ang katawan, kaya para sa script na tumatawag ito ay kasing walang silbi ng pag-time out.
Ang ikaapat na hanay ay kasing karaniwan sa mas lumang mga stack ng PHP at balangkas. Ang babala tungkol sa deprecation na nakalimbag bago ang naka-encode na payload ay gumagawa ng katawan na hindi tatanggapin ng anumang parser ng JSON, at madalas ang babalang iyon ang buong paliwanag.
Hakbang 4: basahin ang error ng parser nang literal
Pinapangalanan ng teksto ng error ang unang karakter na sumira sa pag-parse, at iyon ay karaniwang tumutukoy sa kategorya nang walang anumang hula.
| 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 |
Ang walang laman na katawan na may 200 ay sariling kaso: tumakbo ang endpoint, walang ginawa, at may isang bagay sa ibaba na itinuring itong tagumpay. Ito ay kabiguan ng kontrata ng aplikasyon at hindi ng transportasyon, at ang lugar nito ay sa susunod na hakbang, hindi sa proxy. Iba ang pagpapahayag ng Firefox at Safari sa parehong apat na kabiguan, kaya itugma sa karakter o sa walang laman na katawan at hindi sa eksaktong string.
Hakbang 5: ayusin ang layer na tinutukoy ng ebidensya
Para sa problema sa routing, ayusin ang kahilingan: itama ang action, pigilan ang handler na mahulog, itugma ang endpoint at paraan, at subukan muli. Para sa problema sa presentasyon, ayusin ang gumawa ng katawan, at alamin kung bakit bumabalik ang dokumento ng error doon kung saan inaasahan ang data. Para sa problema sa kontrata, basahin ang aktuwal na inaasahang istruktura ng balangkas para sa bersyong pinapatakbo mo, at hubugin ang tugon ayon doon sa halip na luwagan ang kliyente.
Ang tugon na may naka-block na access ay nangangailangan ng sariling pag-ikot, dahil ang kahilingan mismo ay maaaring tama at ang katawan ay maaaring hindi kailanman makarating sa iyong code. Ihambing ang Access-Control-Allow-Origin ng tugon sa eksaktong Origin na ipinadala ng browser, at tandaan na ang wildcard ay hindi tumutugon sa kahilingang may kredensyal. Ipares ang credentials: 'include' sa kliyente sa Access-Control-Allow-Credentials: true sa server, at suriin kung ginamit ng tawag ang mode na no-cors, kung saan ang malabong katawan ay dokumentadong resulta at hindi depekto.
Ang palitan ang parser ng isang mas mapagbigay ay ang tanging pagwawastong dapat iwasan. Ang suriin ang tugon bilang code, o ang balatan ang teksto hanggang ma-parse ito, ay nagtatago ng hindi pagtutugma ng kontrata at nagdaragdag ng ibabaw ng iniksyon kapalit ng katahimikan. Gayundin, kailangang suriin ang katayuan nang hiwalay sa katawan: ang 200 na may object ng error sa antas ng aplikasyon ay karaniwan sa maraming API at dapat pangasiwaan sa pamamagitan ng pagbasa ng payload.
Kapag kailangan mo ng tulong ng iba, ibahagi ang pinakamaliit na tala — paraan, URL, katayuan, huling URL pagkatapos ng mga redirect, uri ng nilalaman ng tugon, hugis ng katawan at ang inaasahang kontrata — sa halip na hilaw na export. Naglalaman ang mga archive ng network ng cookies, token, query string at ang personal na datos na nasa form, at ang awtomatikong tagalinis ay hindi pagsusuri.
- Huwag palampasin ang kahilingan nang walang filter bago baguhin ang anumang code.
- Tiyakin na ang nagpasimula ay ang iyong script at ang huling URL ay ang iyong endpoint.
- Uriin ang tugon bago hawakan ang parser.
- Ayusin ang routing, access, presentasyon o kontrata, at hindi kailanman sa pamamagitan ng pagluwag sa parser.