Un formulari AJAX espera JSON però rep HTML: ressegueix la resposta pas a pas
Una resposta 200 no demostra que sigui JSON. Recorre el tauler Xarxa pas a pas i separa les fallades de transport, de representació i de contracte.
El formulari s’envia, apareix l’indicador i la consola diu que hi ha un símbol < inesperat a JSON a la posició 0. La pàgina es carrega bé, i per això el primer impuls és culpar l’analitzador o el túnel. Normalment no hi intervé cap dels dos: l’enviament és una petició diferent de la càrrega de la pàgina, i ha tornat amb una cosa que no és JSON. Treballa en l’ordre en què el navegador ho revela de debò, perquè les quatre respostes possibles necessiten quatre correccions diferents.
Pas 1: captura l’enviament que ha passat realment
Obre el tauler Xarxa abans d’enviar, posa el registre a conservar les entrades entre navegacions i fes un enviament de prova inofensiu amb un compte que tinguis permès d’usar. Tria la petició que ha iniciat el formulari mateix, no la petició del document de la pàgina.
Ves amb compte amb els filtres. Un filtre XHR o Fetch és còmode, però si el marc encara envia per un iframe ocult o per un formulari creat dinàmicament, el filtre amagarà l’única petició que importa. Envia primer un cop sense filtre i mira què ha aparegut.
Per a la petició triada, anota sis coses abans d’interpretar res: el mètode, l’URL complet amb la cadena de consulta, l’estat, la cadena de redireccions, el Content-Type de la resposta i les primeres línies del cos. La referència del tauler Xarxa de Chrome DevTools cobreix les vistes Headers, Response i Initiator on es troben, i els taulers equivalents d’altres navegadors mostren els mateixos camps.
Pas 2: confirma que és la petició que penses
Una quantitat sorprenent d’errors de JSON són en realitat errors d’encaminament. Si el gestor de l’enviament llança una excepció abans de cridar preventDefault, el navegador fa un POST natiu del formulari a l’adreça de l’atribut action, i el servidor respon amb una pàgina HTML completa. El gestor no s’executa mai, o sigui que no s’ha demanat cap JSON.
Compara l’URL del tauler amb l’URL que crida el teu JavaScript. Busca una redirecció que acabi en un altre lloc, una barra final que falti o que sobri, un desajust de mètode quan el gestor envia GET i el punt final accepta POST, o un formulari que envia a un camí relatiu des d’una pàgina que s’ha mogut. Segueix la cadena de redireccions fins al final i anota l’URL final, no la primera.
Després comprova l’iniciador. Si la petició ha vingut d’una navegació de document i no del teu script, ja has trobat el problema, i cap canvi a l’analitzador de resposta no ajudarà.
Pas 3: classifica el resultat en quatre categories
Cada resultat pertany exactament a una d’aquestes, i la categoria decideix on mirar després.
| 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 |
Les files del mig són les que la gent diagnostica malament, perquè l’estat és 200. Una pàgina d’inici de sessió a què s’arriba després d’una redirecció és una resposta HTTP perfectament bona i un document JSON molt dolent. El tipus de contingut application/json no ho arregla: és una etiqueta, i un cos mal etiquetat continua fallant en analitzar-se. Accés bloquejat és la fila que sembla una petició completada: el tauler mostra un estat, però la política d’orígens creuats reté el cos, i per a l’script que crida és tan inservible com un temps d’espera exhaurit.
La quarta fila és igual de freqüent en piles PHP i de marcs més antigues. Un avís de desaprovació imprès abans de la càrrega codificada produeix un cos que cap analitzador JSON acceptarà, i sovint aquest avís és tota l’explicació.
Pas 4: llegeix l’error de l’analitzador literalment
El text de l’error anomena el primer caràcter que ha trencat l’anàlisi, cosa que normalment identifica la categoria sense cap conjectura.
| 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 |
Un cos buit amb un 200 és un cas propi: el punt final s’ha executat, no ha produït res i alguna cosa més avall ho ha pres com un èxit. És una fallada de contracte d’aplicació i no de transport, i el seu lloc és el pas següent, no el proxy. Firefox i Safari formulen les mateixes quatre fallades d’una altra manera, així que compara pel caràcter o pel cos buit i no per la cadena exacta.
Pas 5: corregeix la capa que assenyalen les proves
Per a un problema d’encaminament, corregeix la petició: arregla l’action, evita que el gestor caigui, fes que el punt final i el mètode coincideixin i torna a provar. Per a un problema de representació, corregeix què ha produït el cos i esbrina per què es retorna un document d’error on s’esperaven dades. Per a un problema de contracte, llegeix l’estructura real que el marc espera per a la versió que executes i dona forma a la resposta segons ella en lloc d’afluixar el client.
Una resposta amb accés bloquejat necessita la seva pròpia passada, perquè la petició pot ser correcta i el cos pot no arribar mai al teu codi. Compara l’Access-Control-Allow-Origin de la resposta amb l’Origin exacte que ha enviat el navegador, i recorda que un comodí no satisfà una petició amb credencials. Emparella credentials: 'include' al client amb Access-Control-Allow-Credentials: true al servidor, i comprova si la crida ha usat el mode no-cors, on un cos opac és el resultat documentat i no un error.
Substituir l’analitzador per una cosa permissiva és l’única correcció que cal evitar. Avaluar la resposta com a codi, o pelar el text fins que s’analitzi, amaga el desajust de contracte i afegeix una superfície d’injecció a canvi de silenci. Igualment, cal comprovar l’estat per separat del cos: un 200 que porta un objecte d’error a nivell d’aplicació és normal en moltes API i s’ha de gestionar llegint la càrrega.
Quan necessitis ajuda d’algú altre, comparteix un registre mínim — mètode, URL, estat, URL final després de les redireccions, tipus de contingut de la resposta, forma del cos i contracte esperat — en lloc d’una exportació crua. Els arxius de xarxa contenen galetes, testimonis, cadenes de consulta i les dades personals que hi havia al formulari, i un sanejador automàtic no és una revisió.
- Captura la petició sense filtre abans de canviar cap codi.
- Confirma que l’iniciador era el teu script i que l’URL final és el teu punt final.
- Classifica la resposta abans de tocar l’analitzador.
- Corregeix encaminament, accés, representació o contracte, i mai afluixant l’analitzador.