Një formular AJAX pret JSON por merr HTML: ndiq përgjigjen hap pas hapi
Një përgjigje 200 nuk është provë se është JSON. Kaloni nëpër panelin Rrjeti hap pas hapi dhe ndani dështimet e transportit, të paraqitjes dhe të kontratës.
Formulari dërgohet, rrotulluesi shfaqet dhe konsola thotë se ka një shenjë < të papritur në JSON në pozicionin 0. Vetë faqja ngarkohet mirë, prandaj instinkti i parë është të fajësosh analizuesin ose tunelin. Zakonisht asnjëri nuk është i përfshirë: dërgimi është një kërkesë tjetër nga ngarkimi i faqes, dhe u kthye me diçka që nuk është JSON. Punoni në rendin që shfletuesi e zbulon vërtet, sepse katër përgjigjet e mundshme kërkojnë katër rregullime të ndryshme.
Hapi 1: kapni dërgimin që ndodhi vërtet
Hapni panelin Rrjeti para se të dërgoni, vendosni regjistrin të ruajë hyrjet gjatë navigimit dhe më pas bëni një dërgim testues të padëmshëm në një llogari që ju lejohet ta përdorni. Zgjidhni kërkesën që nisi vetë formulari, jo kërkesën e dokumentit të faqes.
Kini kujdes me filtrat. Një filtër XHR ose Fetch është i përshtatshëm, por nëse korniza ende dërgon përmes një iframe të fshehur ose një formulari të krijuar në mënyrë dinamike, filtri do të fshehë kërkesën e vetme me rëndësi. Dërgoni fillimisht një herë pa filtër dhe shikoni çfarë u shfaq.
Për kërkesën e zgjedhur, shkruani gjashtë gjëra përpara çdo interpretimi: metodën, URL-në e plotë me vargun e kërkesës, statusin, zinxhirin e ridrejtimeve, Content-Type e përgjigjes dhe rreshtat e parë të trupit. Referenca e panelit Rrjeti në Chrome DevTools mbulon pamjet Headers, Response dhe Initiator ku ndodhen këto, dhe panelet ekuivalente në shfletuesit e tjerë tregojnë të njëjtat fusha.
Hapi 2: konfirmoni se është kërkesa që mendoni
Një numër befasues i gabimeve JSON janë në të vërtetë gabime rrugëtimi. Nëse trajtuesi i dërgimit hedh një përjashtim përpara se të thërrasë preventDefault, shfletuesi kryen një POST natyral të formularit në adresën që tregon atributi action, dhe serveri përgjigjet me një faqe të plotë HTML. Trajtuesi nuk ekzekutohet kurrë, pra JSON nuk u kërkua kurrë.
Krahasoni URL-në në panel me URL-në që thërret JavaScript-i juaj. Kërkoni një ridrejtim që përfundon diku tjetër, një vizë të pjerrët mbyllëse që mungon ose është e tepërt, një mospërputhje metode kur trajtuesi dërgon GET dhe pika fundore pranon POST, ose një formular që dërgon në një shteg relativ nga një faqe që është zhvendosur. Ndiqni zinxhirin e ridrejtimeve deri në fund dhe shënoni URL-në përfundimtare, jo të parën.
Më pas kontrolloni nisësin. Nëse kërkesa erdhi nga navigimi i dokumentit dhe jo nga skripti juaj, e keni gjetur problemin, dhe asnjë ndryshim në analizuesin e përgjigjes nuk do të ndihmojë.
Hapi 3: klasifikoni rezultatin në katër kategori
Çdo rezultat i përket saktësisht njërës prej tyre, dhe kategoria vendos ku të shikoni më pas.
| 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 |
Rreshtat e mesëm janë ata që njerëzit i diagnostikojnë gabimisht, sepse statusi është 200. Një faqe hyrjeje e arritur pas një ridrejtimi është një përgjigje HTTP plotësisht e mirë dhe një dokument JSON shumë i dobët. Lloji i përmbajtjes application/json nuk e rregullon këtë: është një etiketë, dhe një trup i etiketuar gabimisht përsëri nuk analizohet. Qasja e bllokuar është rreshti që duket si kërkesë e përfunduar: paneli tregon një status, por politika e origjinës së kryqëzuar e mban trupin, kështu që për skriptin që thërret është po aq i papërdorshëm sa një skadim kohe.
Rreshti i katërt është po aq i zakonshëm në stivët e vjetër të PHP dhe të kornizave. Një paralajmërim për vjetërim të printuar përpara ngarkesës së koduar prodhon një trup që asnjë analizues JSON nuk e pranon, dhe shpesh ai paralajmërim është i gjithë shpjegimi.
Hapi 4: lexoni gabimin e analizuesit fjalë për fjalë
Teksti i gabimit emërton karakterin e parë që theu analizimin, dhe kjo zakonisht identifikon kategorinë pa asnjë hamendje.
| 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 |
Një trup bosh me 200 është rast më vete: pika fundore ekzekutohet, nuk prodhoi asgjë dhe diçka më poshtë e trajtoi si sukses. Ky është një dështim i kontratës së aplikacionit dhe jo i transportit, dhe vendi i tij është në hapin tjetër, jo në përfaqësues. Firefox dhe Safari i formulojnë ndryshe të njëjtat katër dështime, prandaj përputhni sipas karakterit ose trupit bosh dhe jo sipas vargut të saktë.
Hapi 5: rregulloni shtresën që tregojnë provat
Për një problem rrugëtimi, rregulloni kërkesën: korrigjoni action, pengoni trajtuesin të bjerë, përputhni pikën fundore dhe metodën dhe provoni përsëri. Për një problem paraqitjeje, rregulloni atë që prodhoi trupin dhe zbuloni pse kthehet një dokument gabimi atje ku priteshin të dhëna. Për një problem kontrate, lexoni strukturën e vërtetë që korniza pret për versionin që ekzekutoni dhe formoni përgjigjen sipas saj, në vend që të lironi klientin.
Përgjigja me qasje të bllokuar kërkon kalimin e vet, sepse vetë kërkesa mund të jetë e saktë dhe trupi mund të mos arrijë kurrë në kodin tuaj. Krahasoni Access-Control-Allow-Origin e përgjigjes me Origin-in e saktë që dërgoi shfletuesi, dhe mbani mend se një karakter i përgjithshëm nuk plotëson një kërkesë me kredenciale. Çiftëzoni credentials: 'include' në klient me Access-Control-Allow-Credentials: true në server dhe kontrolloni nëse thirrja përdori modalitetin no-cors, ku një trup i errët është rezultati i dokumentuar dhe jo një defekt.
Zëvendësimi i analizuesit me diçka më të butë është rregullimi i vetëm që duhet shmangur. Vlerësimi i përgjigjes si kod, ose qërimi i tekstit derisa të analizohet, fsheh mospërputhjen e kontratës dhe shton një sipërfaqe injektimi në këmbim të heshtjes. Po ashtu, kontrolli i statusit veçmas nga trupi është i detyrueshëm: një 200 që mban një objekt gabimi në nivel aplikacioni është normal në shumë API dhe duhet trajtuar duke lexuar ngarkesën.
Kur ju duhet ndihma e dikujt tjetër, ndani një regjistrim minimal — metodë, URL, status, URL përfundimtare pas ridrejtimeve, lloji i përmbajtjes së përgjigjes, forma e trupit dhe kontrata e pritur — në vend të një eksporti të papërpunuar. Arkivat e rrjetit përmbajnë cookie, token, vargje kërkese dhe të dhënat personale që ishin në formular, dhe një pastrues automatik nuk është rishikim.
- Kapni kërkesën pa filtër përpara se të ndryshoni çdo kod.
- Konfirmoni se nisësi ishte skripti juaj dhe URL-ja përfundimtare është pika juaj fundore.
- Klasifikoni përgjigjen përpara se të prekni analizuesin.
- Rregulloni rrugëtimin, qasjen, paraqitjen ose kontratën, dhe kurrë duke liruar analizuesin.