Az AJAX űrlap JSON-t vár, de HTML-t kap: lépésről lépésre vizsgáljuk a választ
A 200-as válasz nem bizonyíték arra, hogy JSON. Járjuk végig a Hálózat panelt lépésről lépésre, és válasszuk szét a szállítási, megjelenítési és szerződéses hibákat.
Az űrlap elküldődik, megjelenik a töltő, és a konzol azt írja, hogy váratlan < token van a JSON-ban a 0. pozícióban. Maga az oldal szépen betöltődik, ezért az első ösztön a parsert vagy az alagutat hibáztatni. Általában egyik sem érintett: a beküldés más kérés, mint az oldal betöltése, és valami olyannal tért vissza, ami nem JSON. Abban a sorrendben dolgozz, ahogy a böngésző valóban felfedi, mert a négy lehetséges válasz négy különböző javítást igényel.
1. lépés: rögzítsd a ténylegesen megtörtént beküldést
Nyisd meg a Hálózat panelt küldés előtt, állítsd a naplót úgy, hogy a bejegyzések navigációk között is megmaradjanak, majd végezz egy ártalmatlan próbaküldést egy olyan fiókkal, amelyet használhatsz. Azt a kérést válaszd, amelyet maga az űrlap indított, ne az oldal dokumentumkérését.
Vigyázz a szűrőkkel. Az XHR vagy Fetch szűrő kényelmes, de ha a keretrendszer még mindig rejtett iframe-en vagy dinamikusan létrehozott űrlapon keresztül küld, a szűrő elrejti az egyetlen fontos kérést. Először egyszer szűrő nélkül küldj, és nézd meg, mi jelent meg.
A kiválasztott kéréshez hat dolgot jegyezz fel, mielőtt bármit értelmeznél: a metódust, a teljes URL-t a lekérdezési karakterlánccal, a státuszt, az átirányítási láncot, a válasz Content-Type-ját és a törzs első sorait. A Chrome DevTools Hálózat panel referenciája lefedi a Headers, Response és Initiator nézeteket, ahol ezek vannak, és a többi böngésző egyenértékű paneljei ugyanezeket a mezőket mutatják.
2. lépés: erősítsd meg, hogy valóban arra a kérésre gondolsz
Meglepően sok JSON-hiba valójában útválasztási hiba. Ha a beküldéskezelő kivételt dob, mielőtt meghívná a preventDefaultot, a böngésző natív űrlap-POST-ot hajt végre arra a címre, amit az action attribútum megad, és a kiszolgáló egy teljes HTML-oldallal válaszol. A kezelő soha nem fut le, tehát JSON-t soha nem kértek.
Hasonlítsd össze a panelen látható URL-t azzal, amit a JavaScripted hív. Keress olyan átirányítást, amely máshol végződik, hiányzó vagy felesleges záró perjelet, metódus-eltérést, amikor a kezelő GET-et küld, a végpont pedig POST-ot fogad, vagy olyan űrlapot, amely egy elköltözött oldalról relatív útvonalra küld. Kövesd az átirányítási láncot a végéig, és a végső URL-t jegyezd fel, nem az elsőt.
Ezután ellenőrizd a kezdeményezőt. Ha a kérés dokumentumnavigációból érkezett, és nem a szkriptedből, már megtaláltad a problémát, és a válaszparser módosítása nem segít.
3. lépés: sorold be az eredményt négy kategóriába
Minden eredmény pontosan egybe tartozik ezek közül, és a kategória dönti el, hova nézz tovább.
| 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 |
A középső sorokat szokták rosszul diagnosztizálni, mert a státusz 200. Az átirányítás után elért bejelentkező oldal teljesen jó HTTP-válasz és nagyon rossz JSON-dokumentum. Az application/json tartalomtípus ezt nem javítja: ez csak egy címke, és a rosszul címkézett törzs továbbra sem parsolható. A hozzáférés blokkolva az a sor, amely befejezett kérésnek látszik: a panel státuszt mutat, de a kereszt-origin szabályzat visszatartja a törzset, így a hívó szkript számára ugyanolyan használhatatlan, mint egy időtúllépés.
A negyedik sor ugyanilyen gyakori a régebbi PHP- és keretrendszer-veremeken. A kódolt terhelés előtt kiírt elavulási figyelmeztetés olyan törzset hoz létre, amelyet egyetlen JSON-parser sem fogad el, és gyakran ez a figyelmeztetés a teljes magyarázat.
4. lépés: olvasd szó szerint a parser hibáját
A hibaüzenet megnevezi az első karaktert, amely megtörte a parsolást, és ez általában minden találgatás nélkül azonosítja a kategóriát.
| 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 |
Az üres törzs 200-zal külön eset: a végpont lefutott, semmit nem termelt, és valami lejjebb sikernek tekintette. Ez alkalmazásszerződés-hiba, nem szállítási hiba, és a helye a következő lépésben van, nem a proxyban. A Firefox és a Safari ugyanezt a négy hibát másképp fogalmazza meg, ezért a karakterre vagy az üres törzsre illeszd, ne a pontos karakterláncra.
5. lépés: javítsd azt a réteget, amelyre a bizonyítékok mutatnak
Útválasztási probléma esetén a kérést javítsd: javítsd az actiont, akadályozd meg a kezelő kiesését, hozd összhangba a végpontot és a metódust, majd tesztelj újra. Megjelenítési probléma esetén azt javítsd, ami a törzset létrehozta, és derítsd ki, miért hibadokumentum jön vissza ott, ahol adatot vártak. Szerződéses probléma esetén olvasd el a keretrendszer tényleges elvárt szerkezetét a futtatott verzióhoz, és ahhoz formáld a választ ahelyett, hogy meglazítanád a klienst.
A blokkolt hozzáférésű válasz külön körutat igényel, mert maga a kérés lehet helyes, és a törzs sosem érhet el a kódodig. Hasonlítsd össze a válasz Access-Control-Allow-Origin fejlécét a böngésző által küldött pontos Origin értékkel, és ne feledd, hogy a helyettesítő karakter nem elégít ki hitelesítő adatokkal járó kérést. Párosítsd a kliensen a credentials: 'include' beállítást a kiszolgálón a Access-Control-Allow-Credentials: true fejléccel, és ellenőrizd, hogy a hívás nem a no-cors módot használta-e, ahol az átlátszatlan törzs dokumentált eredmény, nem hiba.
A parser lecserélése valami megengedőbbre az egyetlen javítás, amit el kell kerülni. A válasz kódként való kiértékelése vagy a szöveg lehámozása addig, amíg parsolható lesz, elrejti a szerződéseltérést, és csendért cserébe injekciós felületet ad. Ugyanígy a státuszt a törzstől elkülönítve kell ellenőrizni: a 200 alkalmazásszintű hibaobjektummal sok API-ban normális, és a terhelés olvasásával kell kezelni.
Ha más segítségére van szükséged, minimalizált feljegyzést ossz meg — metódus, URL, státusz, az átirányítások utáni végső URL, a válasz tartalomtípusa, a törzs alakja és az elvárt szerződés — nyers export helyett. A hálózati archívumok sütiket, tokeneket, lekérdezési karakterláncokat és az űrlapban lévő személyes adatokat tartalmaznak, az automatikus tisztító pedig nem átvizsgálás.
- Rögzítsd a kérést szűrő nélkül, mielőtt bármilyen kódot módosítasz.
- Erősítsd meg, hogy a kezdeményező a szkripted volt, és a végső URL a végpontod.
- Sorold be a választ, mielőtt a parserhez nyúlsz.
- Javítsd az útválasztást, a hozzáférést, a megjelenítést vagy a szerződést, és soha ne a parser lazításával.