Ett AJAX-formulär väntar på JSON men får HTML: gå igenom svaret steg för steg
Ett 200-svar bevisar inte att det är JSON. Gå igenom Nätverks-panelen steg för steg och skilj fel i transport, representation och kontrakt.
Formuläret skickas, snurran visas och konsolen säger att det finns en oväntad token < i JSON på position 0. Sidan laddas fint, och därför är den första impulsen att skylla på parsern eller tunneln. Oftast är ingen av dem inblandad: inskickningen är en annan begäran än sidladdningen, och den kom tillbaka med något som inte är JSON. Arbeta i den ordning webbläsaren faktiskt avslöjar det, eftersom de fyra möjliga svaren kräver fyra olika rättelser.
Steg 1: fånga inskickningen som verkligen skedde
Öppna Nätverks-panelen innan du skickar, ställ in loggen så att poster bevaras mellan navigeringar, och gör sedan en ofarlig testinskickning på ett konto du får använda. Välj den begäran som formuläret självt startade, inte sidans dokumentbegäran.
Var försiktig med filter. Ett XHR- eller Fetch-filter är bekvämt, men om ramverket fortfarande skickar via en dold iframe eller ett dynamiskt skapat formulär, döljer filtret den enda begäran som spelar roll. Skicka först en gång utan filter och titta på vad som dök upp.
För den valda begäran, anteckna sex saker innan du tolkar något: metoden, hela URL:en med frågesträngen, statusen, omdirigeringskedjan, svarets Content-Type och de första raderna i kroppen. Referensen för Nätverks-panelen i Chrome DevTools täcker vyerna Headers, Response och Initiator där detta finns, och motsvarande paneler i andra webbläsare visar samma fält.
Steg 2: bekräfta att det är begäran du tror
Ett överraskande antal JSON-fel är i själva verket routingfel. Om inskickningshanteraren kastar innan den anropar preventDefault, utför webbläsaren en inbyggd formulär-POST till adressen i action-attributet, och servern svarar med en fullständig HTML-sida. Hanteraren körs aldrig, så JSON efterfrågades aldrig.
Jämför URL:en i panelen med den URL som din JavaScript anropar. Leta efter en omdirigering som slutar någon annanstans, ett saknat eller överflödigt snedstreck i slutet, en metodmissmatchning där hanteraren skickar GET och slutpunkten tar emot POST, eller ett formulär som skickar till en relativ sökväg från en sida som flyttat. Följ omdirigeringskedjan till slutet och notera den slutliga URL:en, inte den första.
Kontrollera sedan initieraren. Om begäran kom från en dokumentnavigering och inte från ditt skript, har du redan hittat problemet, och ingen ändring i en svarsparser hjälper.
Steg 3: sortera resultatet i fyra kategorier
Varje resultat hör till exakt en av dessa, och kategorin avgör var du tittar härnäst.
| 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 |
De mellersta raderna är de som feldiagnostiseras, eftersom statusen är 200. En inloggningssida som nås efter en omdirigering är ett fullständigt bra HTTP-svar och ett mycket dåligt JSON-dokument. Innehållstypen application/json reparerar inte det: det är en etikett, och en felmärkt kropp går fortfarande inte att parsa. Åtkomst blockerad är raden som ser ut som en avslutad begäran: panelen visar en status, men policyn för korsande ursprung håller kvar kroppen, så för det anropande skriptet är den lika oanvändbar som en timeout.
Den fjärde raden är lika vanlig på äldre PHP- och ramverksstackar. En avskrivningsvarning som skrivs ut före den kodade lasten ger en kropp som ingen JSON-parser accepterar, och ofta är den varningen hela förklaringen.
Steg 4: läs parserfelet bokstavligt
Feltexten namnger det första tecknet som bröt parsningen, och det identifierar oftast kategorin utan någon gissning.
| 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 |
En tom kropp med 200 är ett eget fall: slutpunkten kördes, producerade ingenting, och något längre ned behandlade det som framgång. Det är ett kontraktsfel i applikationen och inte i transporten, och det hör hemma i nästa steg, inte i proxyn. Firefox och Safari formulerar samma fyra fel annorlunda, så matcha på tecknet eller på den tomma kroppen och inte på den exakta strängen.
Steg 5: rätta lagret som bevisen pekar på
Vid ett routingproblem, rätta begäran: korrigera action, hindra hanteraren från att falla igenom, få slutpunkt och metod att stämma och testa igen. Vid ett representationsproblem, rätta det som producerade kroppen och ta reda på varför ett feldokument returneras där data förväntades. Vid ett kontraktsproblem, läs ramverkets faktiskt förväntade struktur för den version du kör och forma svaret efter den i stället för att lossa klienten.
Ett svar med blockerad åtkomst behöver sin egen genomgång, eftersom begäran själv kan vara korrekt och kroppen kanske aldrig når din kod. Jämför svarets Access-Control-Allow-Origin med den exakta Origin som webbläsaren skickade, och kom ihåg att ett jokertecken inte uppfyller en begäran med inloggningsuppgifter. Para ihop credentials: 'include' på klienten med Access-Control-Allow-Credentials: true på servern, och kontrollera om anropet använde läget no-cors, där en ogenomskinlig kropp är det dokumenterade resultatet och inte en defekt.
Att ersätta parsern med något efterlåtande är den enda rättelse man bör undvika. Att utvärdera svaret som kod, eller att skala bort text tills det parsas, döljer kontraktmismatchen och lägger till en injektionsyta i utbyte mot tystnad. På samma sätt måste statusen kontrolleras separat från kroppen: en 200 med ett felobjekt på applikationsnivå är normalt i många API:er och måste hanteras genom att läsa lasten.
När du behöver hjälp av någon annan, dela en minimal post — metod, URL, status, slutlig URL efter omdirigeringar, svarets innehållstyp, kroppens form och det förväntade kontraktet — i stället för en rå export. Nätverksarkiv innehåller kakor, tokens, frågesträngar och de personuppgifter som fanns i formuläret, och en automatisk rensare är inte en granskning.
- Fånga begäran utan filter innan du ändrar någon kod.
- Bekräfta att initieraren var ditt skript och att den slutliga URL:en är din slutpunkt.
- Klassificera svaret innan du rör parsern.
- Rätta routing, åtkomst, representation eller kontrakt, och aldrig genom att lossa parsern.