Obrazec AJAX pričakuje JSON, a prejme HTML: preglejte odgovor korak za korakom
Odgovor s statusom 200 ni dokaz, da gre za JSON. Pojdite skozi ploščo Omrežje korak za korakom in ločite napake prenosa, predstavitve in pogodbe.
Obrazec se pošlje, prikaže se vrtavka in konzola sporoči, da je v JSON na položaju 0 nepričakovan znak <. Sama stran se naloži dobro, zato je prvi impulz kriviti razčlenjevalnik ali tunel. Običajno ni vpleten noben od njiju: pošiljanje je druga zahteva kot nalaganje strani, in vrnilo se je z nečim, kar ni JSON. Delajte v vrstnem redu, v katerem brskalnik to res razkrije, ker štirje možni odgovori zahtevajo štiri različne popravke.
Korak 1: ujemite pošiljanje, ki se je res zgodilo
Odprite ploščo Omrežje pred pošiljanjem, nastavite dnevnik tako, da ohrani vnose med navigacijami, nato pa opravite eno neškodljivo preizkusno pošiljanje na računu, ki ga smete uporabljati. Izberite zahtevo, ki jo je sprožil obrazec sam, ne zahteve dokumenta strani.
Bodite previdni s filtri. Filter XHR ali Fetch je priročen, a če ogrodje še vedno pošilja prek skritega iframe ali dinamično ustvarjenega obrazca, bo filter skril edino pomembno zahtevo. Najprej pošljite enkrat brez filtra in poglejte, kaj se je pojavilo.
Pri izbrani zahtevi zapišite šest stvari, preden karkoli razlagate: metodo, celoten URL skupaj z nizom poizvedbe, status, verigo preusmeritev, Content-Type odgovora in prve vrstice telesa. Referenca plošče Omrežje v Chrome DevTools pokriva poglede Headers, Response in Initiator, kjer je to, in enakovredne plošče v drugih brskalnikih kažejo ista polja.
Korak 2: potrdite, da je to zahteva, ki jo mislite
Presenetljivo veliko napak JSON je v resnici napak usmerjanja. Če upravljalnik pošiljanja vrže izjemo, preden pokliče preventDefault, brskalnik izvede izvorni POST obrazca na naslov iz atributa action, strežnik pa odgovori s celotno stranjo HTML. Upravljalnik se nikoli ne izvede, zato JSON ni bil nikoli zahtevan.
Primerjajte URL na plošči z URL, ki ga kliče vaš JavaScript. Iščite preusmeritev, ki se konča drugje, manjkajočo ali odvečno poševnico na koncu, neskladje metode, ko upravljalnik pošilja GET, končna točka pa sprejema POST, ali obrazec, ki pošilja na relativno pot s strani, ki se je premaknila. Sledite verigi preusmeritev do konca in zapišite končni URL, ne prvega.
Nato preverite začetnika. Če je zahteva prišla iz navigacije dokumenta in ne iz vaše skripte, ste težavo že našli, in nobena sprememba razčlenjevalnika odgovora ne bo pomagala.
Korak 3: razvrstite izid v štiri kategorije
Vsak izid spada točno v eno od teh, kategorija pa odloči, kam pogledate naprej.
| 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 |
Srednje vrstice ljudje napačno diagnosticirajo, ker je status 200. Prijavna stran, dosežena po preusmeritvi, je povsem dober odgovor HTTP in zelo slab dokument JSON. Vrsta vsebine application/json tega ne popravi: to je oznaka, in napačno označeno telo se še vedno ne da razčleniti. Dostop blokiran je vrstica, ki izgleda kot zaključena zahteva: plošča pokaže status, a politika različnih izvorov zadrži telo, zato je za skripto, ki kliče, enako neuporabno kot potek časa.
Četrta vrstica je enako pogosta na starejših skladih PHP in ogrodij. Opozorilo o zastarelosti, natisnjeno pred kodirano obremenitvijo, ustvari telo, ki ga noben razčlenjevalnik JSON ne bo sprejel, in pogosto je to opozorilo cela razlaga.
Korak 4: preberite napako razčlenjevalnika dobesedno
Besedilo napake navede prvi znak, ki je zlomil razčlenjevanje, in to običajno prepozna kategorijo brez vsakega ugibanja.
| 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 |
Prazno telo s 200 je poseben primer: končna točka se je izvedla, ničesar ni ustvarila, in nekaj nižje je to vzelo kot uspeh. To je napaka pogodbe aplikacije, ne prenosa, in njeno mesto je v naslednjem koraku, ne v posredniku. Firefox in Safari istih štirih napak ne oblikujeta enako, zato primerjajte po znaku ali po praznem telesu, ne po točnem nizu.
Korak 5: popravite plast, na katero kažejo dokazi
Pri težavi z usmerjanjem popravite zahtevo: popravite action, preprečite, da bi upravljalnik padel skozi, uskladite končno točko in metodo ter znova preizkusite. Pri težavi s predstavitvijo popravite tisto, kar je ustvarilo telo, in ugotovite, zakaj se dokument napake vrača tja, kjer so bili pričakovani podatki. Pri težavi s pogodbo preberite dejansko pričakovano strukturo ogrodja za različico, ki jo poganjate, in odgovor oblikujte po njej, namesto da popustite odjemalca.
Odgovor z blokiranim dostopom potrebuje svoj prehod, ker je zahteva sama lahko pravilna, telo pa morda nikoli ne doseže vaše kode. Primerjajte Access-Control-Allow-Origin odgovora s točnim Origin, ki ga je poslal brskalnik, in ne pozabite, da nadomestni znak ne zadosti zahteve s poverilnicami. Povežite credentials: 'include' na odjemalcu z Access-Control-Allow-Credentials: true na strežniku in preverite, ali klic ni uporabil načina no-cors, kjer je neprosojno telo dokumentiran izid in ne napaka.
Zamenjava razčlenjevalnika z nečim popustljivejšim je edini popravek, ki se mu je treba izogniti. Ocenjevanje odgovora kot kode ali lupljenje besedila, dokler se ne da razčleniti, skriva neskladje pogodbe in doda površino za vbrizgavanje v zameno za tišino. Prav tako je treba status preverjati ločeno od telesa: 200 s predmetom napake na ravni aplikacije je običajen v mnogih API in ga je treba obravnavati z branjem obremenitve.
Ko potrebujete pomoč nekoga drugega, delite najmanjši zapis — metodo, URL, status, končni URL po preusmeritvah, vrsto vsebine odgovora, obliko telesa in pričakovano pogodbo — namesto surovega izvoza. Omrežni arhivi vsebujejo piškotke, žetone, nize poizvedbe in osebne podatke, ki so bili v obrazcu, in samodejni čistilec ni pregled.
- Ujemite zahtevo brez filtra, preden spremenite katero koli kodo.
- Potrdite, da je bil začetnik vaša skripta in da je končni URL vaša končna točka.
- Razvrstite odgovor, preden se dotaknete razčlenjevalnika.
- Popravite usmerjanje, dostop, predstavitev ali pogodbo, in nikoli s popuščanjem razčlenjevalnika.