AJAX-vorm verwag JSON maar kry HTML: ontleed die antwoord stap vir stap
’n 200-status is nie ’n bewys van JSON nie. Volg die Netwerk-paneel stap vir stap en skei vervoer-, voorstellings- en kontrakfoute.
Die vorm word ingedien, die draaier verskyn, en die konsole sê onverwagte teken < in JSON by posisie 0. Die bladsy self laai reg, en daarom is die eerste instink om die ontleder of die tonnel te blameer. Nie een is gewoonlik betrokke nie: die indiening is ’n ander versoek as die bladsy se laai, en dit het teruggekom met iets wat nie JSON is nie. Werk dit in die volgorde waarin ’n blaaier dit werklik openbaar, want die vier moontlike antwoorde vra vier verskillende regstellings.
Stap 1: vang die indiening wat werklik gebeur het
Maak die Netwerk-paneel oop voordat jy indien, met die log op bewaar oor navigasie, en doen dan een onskadelike toetsindiening op ’n rekening wat jy mag gebruik. Kies die versoek wat die vorm self geïnisieer het, nie die bladsy se dokumentversoek nie.
Pas op met filters. ’n XHR- of Fetch-filter is gerieflik, maar as die raamwerk nog deur ’n versteekte iframe of ’n dinamies geskepte vorm indien, sal filtering die enigste versoek wegsteek wat saak maak. Dien eers een keer sonder filter in en kyk wat verskyn.
Vir die versoek wat jy gekies het, teken ses dinge op voordat jy enigiets interpreteer: metode, volle URL insluitend die navraagstring, status, die herleidingsketting, die antwoord se Content-Type, en die eerste reëls van die liggaam. Die Chrome DevTools Netwerk-paneel-verwysing dek die Headers-, Response- en Initiator-aansigte waar dit sit, en die ekwivalente panele in ander blaaiers wys dieselfde velde.
Stap 2: bevestig dit is die versoek wat jy dink dit is
’n Verrassende aantal JSON-foute is eintlik herleidingsfoute. As die indieningshantering gooi voordat dit preventDefault roep, voer die blaaier ’n native vorm-POST uit na wat die action-kenmerk ook al sê, en die bediener antwoord met ’n volledige HTML-bladsy. Die hantering loop nooit nie, so geen JSON is ooit aangevra nie.
Vergelyk die URL in die paneel met die URL wat jou JavaScript roep. Soek na ’n herleiding wat elders eindig, ’n ontbrekende of ekstra skuinsstreep aan die einde, ’n metode-mismatch waar die hantering GET stuur en die eindpunt POST aanvaar, of ’n vorm wat na ’n relatiewe pad plaas vanaf ’n bladsy wat geskuif het. Volg die herleidingsketting tot die einde en let op die finale URL, nie die eerste nie.
Kontroleer dan die inisieerder. As die versoek van ’n dokumentnavigasie gekom het eerder as jou script, het jy die probleem al gevind, en geen verandering aan ’n antwoordontleder sal help nie.
Stap 3: sorteer die uitkoms in vier kategorieë
Elke resultaat val in presies een van hierdie, en die kategorie bepaal waar jy volgende kyk.
| 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 |
Die middelste rye is dié wat mense verkeerd diagnoseer, want die status is 200. ’n Aanmeldbladsy wat na ’n herleiding bereik word, is ’n heeltemal geldige HTTP-antwoord en ’n verskriklike JSON-dokument. ’n Inhoudstipe van application/json regstel dit nie: dit is ’n etiket, en ’n verkeerd geëtiketteerde liggaam faal steeds om te ontleed. Toegang geblokkeer is die ry wat soos ’n voltooide versoek lyk: die paneel wys ’n status, maar cross-origin-beleid weerhou die liggaam, so vir die roepende script is dit so onbruikbaar soos ’n time-out.
Die vierde ry is ewe algemeen op ouer PHP- en raamwerk-stapels. ’n Waarskuwing oor veroudering wat voor die geënkodeerde vrag gedruk word, lewer ’n liggaam wat geen JSON-ontleder sal aanvaar nie, en die waarskuwing is dikwels die hele verklaring.
Stap 4: lees die ontlederfout letterlik
Die foutteks noem die eerste karakter wat die ontleding gebreek het, wat gewoonlik die kategorie identifiseer sonder enige raai.
| 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 |
’n Leë liggaam met ’n 200 is sy eie geval: die eindpunt het geloop, niks geproduseer nie, en iets stroomaf het dit as sukses behandel. Dit is ’n toepassingskontrakfout eerder as ’n vervoerfout, en dit hoort in die volgende stap eerder as in die proxy. Firefox en Safari verwoord dieselfde vier falings anders, so pas op die karakter of op die leë liggaam eerder as op die presiese string.
Stap 5: regstel die laag waarheen die bewyse wys
Vir ’n herleidingsprobleem, regstel die versoek: korrigeer die action, keer dat die hantering deurval, laat die eindpunt en metode ooreenstem, en toets weer. Vir ’n voorstellingsprobleem, regstel wat die liggaam geproduseer het, en vind uit waarom ’n foutdokument teruggegee word waar data verwag is. Vir ’n kontrakprobleem, lees die raamwerk se werklike verwagte struktuur vir die weergawe wat jy hardloop, en vorm die antwoord daarvolgens eerder as om die kliënt los te maak.
’n Antwoord met toegang geblokkeer het sy eie deurloop nodig, want die versoek self kan korrek wees en die liggaam kan jou kode nooit bereik nie. Vergelyk die antwoord se Access-Control-Allow-Origin met die presiese Origin wat die blaaier gestuur het, en onthou dat ’n wildcard nie ’n versoek met geloofsbriewe bevredig nie. Paar credentials: 'include' aan die kliëntkant met Access-Control-Allow-Credentials: true aan die bedienerkant, en kyk of die oproep no-cors-modus gebruik het, waar ’n ondeursigtige liggaam die gedokumenteerde resultaat is eerder as ’n fout.
Om die ontleder met iets toegeefliks te vervang is die een regstelling om te vermy. Om die antwoord as kode te evalueer, of teks te stroop totdat dit ontleed, verberg die kontrakmismatch en voeg ’n inspuitingsoppervlak by in ruil vir stilte. Net so is dit nodig om die status apart van die liggaam te kontroleer: ’n 200 met ’n toepassingsvlak-foutobjek is normaal in baie API’s en moet hanteer word deur die vrag te lees.
Wanneer jy hulp van iemand anders nodig het, deel ’n minimale rekord — metode, URL, status, finale URL na herleidings, antwoord-inhoudstipe, liggaamsvorm, en die verwagte kontrak — eerder as ’n rou uitvoer. Netwerk-argiewe bevat koekies, tekens, navraagstringe en die persoonlike data wat in die vorm was, en ’n outomatiese saniteerder is nie ’n hersiening nie.
- Vang die versoek sonder filter voordat jy enige kode verander.
- Bevestig die inisieerder was jou script en die finale URL is jou eindpunt.
- Klassifiseer die antwoord voordat jy aan die ontleder raak.
- Regstel herleiding, toegang, voorstelling of kontrak, en nooit deur die ontleder te verslap nie.