AJAX-vorm ootab JSON-i, saab aga HTML-i: vaadake vastus samm-sammult läbi
Vastus staatusega 200 ei tõesta, et tegu on JSON-iga. Käige võrgupaneel samm-sammult läbi ja eraldage transpordi-, esituse- ja lepingutõrked.
Vorm saadetakse ära, spinner ilmub ja konsool teatab ootamatust märgist < JSON-is positsioonil 0. Leht ise laeb hästi, mistõttu on esimene instinkt süüdistada parserit või tunnelit. Tavaliselt ei ole kumbki asjasse segatud: saatmine on lehe laadimisest erinev päring ja see tuli tagasi millegagi, mis ei ole JSON. Töötage selles järjekorras, milles brauser seda tegelikult paljastab, sest neli võimalikku vastust nõuavad nelja erinevat parandust.
Samm 1: püüdke kinni saatmine, mis tegelikult toimus
Avage võrgupaneel enne saatmist, seadistage logi säilitama kirjeid navigeerimise ajal ja tehke seejärel üks kahjutu testsaatmine kontol, mida tohib kasutada. Valige päring, mille käivitas vorm ise, mitte lehe dokumendipäring.
Olge filtritega ettevaatlik. XHR- või Fetch-filter on mugav, aga kui raamistik saadab endiselt peidetud iframe’i või dünaamiliselt loodud vormi kaudu, peidab filter ainsa olulise päringu. Saatke esmalt korra ilma filtriga ja vaadake, mis ilmus.
Valitud päringu kohta kirjutage enne mis tahes tõlgendamist üles kuus asja: meetod, täis-URL koos päringustringiga, staatus, ümbersuunamiste ahel, vastuse Content-Type ja keha esimesed read. Chrome DevToolsi võrgupaneeli viide katab vaated Headers, Response ja Initiator, kus need asuvad, ja teiste brauserite samaväärsed paneelid näitavad samu välju.
Samm 2: veenduge, et see on päring, mida arvate
Üllatavalt palju JSON-vigu on tegelikult marsruutimisvead. Kui saatmise käsitleja viskab erindi enne preventDefault’i kutsumist, teeb brauser natiivse vormi POST-i sinna, kuhu action-atribuut osutab, ja server vastab täieliku HTML-lehega. Käsitleja ei jookse kunagi, seega JSON-i ei küsitudki.
Võrrelge paneeli URL-i URL-iga, mida teie JavaScript kutsub. Otsige ümbersuunamist, mis lõpeb mujal, puuduvat või üleliigset lõpp-kaldkriipsu, meetodi mittevastavust, kus käsitleja saadab GET-i ja lõpp-punkt võtab vastu POST-i, või vormi, mis saadab suhtelisele teele lehelt, mis on liikunud. Jälgige ümbersuunamiste ahelat lõpuni ja märkige üles lõplik URL, mitte esimene.
Seejärel kontrollige algatajat. Kui päring tuli dokumendi navigeerimisest, mitte teie skriptist, olete probleemi juba leidnud ja ükski vastuse parseri muudatus ei aita.
Samm 3: sorteerige tulemus nelja kategooriasse
Iga tulemus kuulub täpselt ühte neist ja kategooria otsustab, kuhu edasi vaadata.
| 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 |
Keskmised read on need, mida inimesed valesti diagnoosivad, sest staatus on 200. Pärast ümbersuunamist jõutud sisselogimisleht on täiesti korralik HTTP-vastus ja väga halb JSON-dokument. Sisu tüüp application/json ei paranda seda: see on silt ja valesti sildistatud keha ei õnnestu ikkagi parsida. Juurdepääs blokeeritud on rida, mis näeb välja nagu lõpetatud päring: paneel näitab staatust, aga päritoludevaheline poliitika hoiab keha kinni, seega kutsuvale skriptile on see sama kasutu kui aegumine.
Neljas rida on sama tavaline vanematel PHP ja raamistike virnadel. Enne kodeeritud koormust trükitud aegumisteade tekitab keha, mida ükski JSON-parser ei võta vastu, ja sageli on see teade kogu selgitus.
Samm 4: lugege parseri viga sõna-sõnalt
Veateade nimetab esimest märki, mis parsimise katki tegi, ja see tuvastab kategooria tavaliselt ilma igasuguse oletuseta.
| 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 |
Tühi keha staatusega 200 on omaette juhtum: lõpp-punkt jooksis, ei tootnud midagi ja miski allpool käsitles seda eduna. See on rakenduse lepingu tõrge, mitte transpordi tõrge, ja selle koht on järgmises sammus, mitte puhverserveris. Firefox ja Safari sõnastavad samad neli tõrget teisiti, seega sobitage märgi või tühja keha järgi, mitte täpse stringi järgi.
Samm 5: parandage kiht, millele tõendid osutavad
Marsruutimisprobleemi puhul parandage päring: korrigeerige action, takistage käsitlejal läbi kukkumast, viige lõpp-punkt ja meetod kooskõlla ning testige uuesti. Esitlusprobleemi puhul parandage see, mis keha tootis, ja uurige välja, miks tagastatakse veadokument seal, kus oodati andmeid. Lepinguprobleemi puhul lugege raamistiku tegelikku oodatavat struktuuri teie jooksutatava versiooni jaoks ja kujundage vastus selle järgi, selle asemel et klienti lõdvendada.
Blokeeritud juurdepääsuga vastus vajab omaette läbivaatust, sest päring ise võib olla korrektne ja keha ei pruugi kunagi teie koodini jõuda. Võrrelge vastuse Access-Control-Allow-Origin’i täpse Origin’iga, mille brauser saatis, ja pidage meeles, et metamärk ei rahulda volitustega päringut. Siduge kliendis credentials: 'include' serveris Access-Control-Allow-Credentials: true-ga ja kontrollige, kas kutse kasutas režiimi no-cors, kus läbipaistmatu keha on dokumenteeritud tulemus, mitte viga.
Parseri asendamine millegi leebemaga on ainus parandus, mida tuleks vältida. Vastuse hindamine koodina või teksti maha kraapimine, kuni see parsitakse, varjab lepingu mittevastavust ja lisab vaikuse eest süstmispinna. Samuti tuleb staatust kehast eraldi kontrollida: 200, mis kannab rakendustasandi veaobjekti, on paljudes API-des tavaline ja seda tuleb käsitleda koormust lugedes.
Kui vajate kellegi teise abi, jagage minimaalset kirjet — meetod, URL, staatus, lõplik URL pärast ümbersuunamisi, vastuse sisutüüp, keha kuju ja oodatav leping — mitte toorandmete eksporti. Võrguarhiivid sisaldavad küpsiseid, žetoone, päringustringe ja isikuandmeid, mis vormis olid, ning automaatne puhastaja ei ole ülevaatus.
- Püüdke päring ilma filtriga kinni enne mis tahes koodi muutmist.
- Veenduge, et algataja oli teie skript ja lõplik URL on teie lõpp-punkt.
- Klassifitseerige vastus enne parseri puutumist.
- Parandage marsruutimine, juurdepääs, esitlus või leping, ja mitte kunagi parserit lõdvendades.