It formulier wurdt ferstjoerd, de spinner ferskynt en de console seit ûnferwacht teken < yn JSON op posysje 0. De side sels laden goed, en dêrom is de earste ympuls om de parser of de tunnel de skuld te jaan. Meastentiids is gjin fan beiden belutsen: de ferstjoering is in oar fersyk as it laden fan de side, en it kaam werom mei eat dat gjin JSON is. Wurkje yn de folchoarder wêryn’t de browser it wier sjen lit, want de fjouwer mooglike antwurden freegje fjouwer ferskillende reparaasjes.

Stap 1: fêstje de ferstjoering dy’t echt barde

Iepenje it Netwurk-paniel foar’t ferstjoer’t, set it logboek sa dat it ynfieringen oer navigaasje hinne bewarret, en doch dan ien ûnskealike testferstjoering op in akkount dat jo brûke meie. Kies it fersyk dat it formulier sels úteinsette, net it dokumintfersyk fan de side.

Wês foarsichtich mei filters. In XHR- of Fetch-filter is handich, mar as it ramt noch altyd ferstjoert fia in ferburgen iframe of in dynamysk makke formulier, dan ferberget it filter it iennige fersyk dat fan belang is. Ferstjoer earst ien kear sûnder filter en sjoch wat der ferskynde.

Foar it keazen fersyk skriuw seis dingen op foar’t jo eat ynterpretearje: de metoade, de folsleine URL mei de query-string, de status, de keatling fan trochstjoeringen, de Content-Type fan it antwurd en de earste rigels fan’t lichem. De referinsje foar it Netwurk-paniel fan Chrome DevTools behannelet de werjeften Headers, Response en Initiator dêr’t dit sit, en de lykweardige panielen yn oare browsers litte deselde fjilden sjen.

Stap 2: befêstigje dat it it fersyk is dat jo tinke

In ferrassend grut part fan de JSON-flaters binne eins flaters yn de rûtelei. As de ôfhandeler fan de ferstjoering in flater smyt foar’t er preventDefault oanropt, docht de browser in natiff formulier-POST nei wat it action-attribút seit, en de tsjinner antwurdet mei in folsleine HTML-side. De ôfhandeler rint nea, dus JSON waard nea frege.

Fergelykje de URL yn it paniel mei de URL dy’t jo JavaScript oanropt. Sykje nei in trochstjoering dy’t earne oars einiget, in ûntbrekkende of oerstallige skúnske streek oan’t ein, in misferstân yn de metoade wêrby’t de ôfhandeler GET stjoert en it einpunt POST akseptearret, of in formulier dat nei in relative paad stjoert fan in side dy’t ferhuze is. Folgje de keatling fan trochstjoeringen oant it ein en skriuw de definitive URL op, net de earste.

Kontrolearje dan de begjinner. As it fersyk fan in dokumintnavigaasje kaam en net fan jo skript, dan hawwe jo it probleem al fûn, en gjin feroaring oan in antwurdparser sil helpe.

Stap 3: yndiele it resultaat yn fjouwer kategoryen

Elk resultaat heart by krekt ien fan dizze, en de kategory beslút wêr’t jo folgjende sjen.

What you seeCategoryWhere to look
Request never finishes, TLS or connection errorNo usable responseEndpoint reachability, certificate, front-end timeout
Request completes, script gets an opaque failureAccess blockedCross-origin policy, credentials mode, missing response header
200 with an HTML body or a login formWrong representationRedirect, expired session, route fallback, error handler
Body begins with a notice then valid JSONWrong representationServer-side warning output before serialisation
Valid JSON, framework rejects itContract mismatchEnvelope shape, field names, value types

De middelste rigels binne dy’t minsken ferkeard diagnostearje, om’t de status 200 is. In oanmeldside dy’t berikt wurdt nei in trochstjoering is in folslein goed HTTP-antwurd en in tige min JSON-dokumint. It ynhâldstype application/json ferbetteret dat net: it is in label, en in ferkeard belabele lichem falt noch altyd by it parsen. Tagong blokkearre is de rigel dy’t op in foltôge fersyk liket: it paniel lit in status sjen, mar it belied foar ferskillende oarsprong hâldt it lichem tsjin, dus foar it skript dat oanropt is it like ûnbrûkber as in tiidferrin.

De fjirde rigel is like gewoan op âldere PHP- en ramtestapels. In warskôging oer ferâldering dy’t foar de kodearre lading printe wurdt, makket in lichem dat gjin inkele JSON-parser akseptearret, en dy warskôging is faak de hiele ferklearring.

Stap 4: lês de parserflater letterlik

De flatertekst neamt it earste teken dat it parsen bruts, en dat identifisearret de kategory meastentiids sûnder hokker rieden dan ek.

Error text (Chrome/V8)What it means
Unexpected token < in JSON at position 0The body starts with markup: an HTML page or an error document
Unexpected end of JSON inputEmpty body, or the response was truncated
Unexpected token o in JSON at position 1You parsed something already parsed, typically an object rather than text
Unexpected token uThe body starts with the bare word undefined, usually an empty response rendered as a string

In leech lichem mei in 200 is in apart gefal: it einpunt rûn, makke neat, en eat fierderop behannele dat as súkses. Dat is in flater yn it kontrakt fan de applikaasje en net yn it ferfier, en it heart yn de folgjende stap, net yn de proxy. Firefox en Safari ferwurdzje deselde fjouwer flaters oars, dus fergelykje op it teken of op it lege lichem en net op de krekte strieng.

Stap 5: reparearje de laach dêr’t it bewiis op wiist

By in probleem mei de rûtelei reparearje jo it fersyk: korrigearje de action, foarkom dat de ôfhandeler der trochhinne falt, lês einpunt en metoade opinoar oan, en test opnij. By in probleem mei de fertsjintwurdiging reparearje jo wat it lichem makke hat, en fine jo út wêrom’t in flaterdokumint weromkomt dêr’t data ferwacht waarden. By in probleem mei it kontrakt lêze jo de wier ferwachte struktuer fan it ramt foar de ferzje dy’t jo draaie, en foarmje it antwurd dêrnei yn stee fan de klient los te litten.

In antwurd mei blokkearre tagong freget syn eigen omgong, om’t it fersyk sels goed wêze kin en it lichem miskien nea by jo koade komt. Fergelykje de Access-Control-Allow-Origin fan it antwurd mei de krekte Origin dy’t de browser stjoerde, en betink dat in wildcard gjin fersyk mei legitimearring foldocht. Keppelje credentials: 'include' by de klient oan Access-Control-Allow-Credentials: true by de tsjinner, en kontrolearje of de oprop de modus no-cors brûkte, dêr’t in ûntrochsichtig lichem it dokumintearre resultaat is en net in brek.

De parser ferfange troch eat toleranter is de iennige reparaasje dy’t jo foarkomme moatte. It antwurd as koade evaluarje, of tekst ôfskilje oant it parset, ferberget de misferstân yn it kontrakt en foeget in oerflak foar ynjeksje ta yn ruil foar stilte. Likegoed is it kontrolearjen fan de status los fan it lichem nedich: in 200 mei in flaterobjekt op applikaasjenivo is gewoan yn in protte API’en en moat behannele wurde troch de lading te lêzen.

As jo help fan immen oars nedich hawwe, diel dan in minimaal oersjoch — metoade, URL, status, definitive URL nei trochstjoeringen, ynhâldstype fan it antwurd, foarm fan it lichem en it ferwachte kontrakt — yn stee fan in rûge eksport. Netwurkargiven befetsje cookies, tokens, query-strings en de persoanlike gegevens dy’t yn it formulier stiene, en in automatyske skjinner is gjin kontrôle.

  • Fêstje it fersyk sûnder filter foar’t jo koade feroarje.
  • Befêstigje dat de begjinner jo skript wie en de definitive URL jo einpunt is.
  • Yndiele it antwurd foar’t jo de parser oanreitsje.
  • Reparearje rûtelei, tagong, fertsjintwurdiging of kontrakt, en nea troch de parser los te litten.

Relatearre artikelen