AJAX formularioak JSON espero du baina HTML jasotzen du: aztertu erantzuna urratsez urrats
200 erantzunak ez du frogatzen JSON denik. Ibili Sarea panela urratsez urrats eta bereizi garraio, irudikapen eta kontratu hutsegiteak.
Formularioa bidaltzen da, erroskila agertzen da, eta kontsolak < ikur espero gabekoa dela dio JSON-en 0 posizioan. Orria bera ondo kargatzen da, eta horregatik lehen bulkada parserari edo tunelari errua botatzea da. Normalean ez dago bat ere tartean: bidalketa orriaren kargatik desberdina den eskaera da, eta JSON ez den zerbait bueltatu da. Jarraitu nabigatzaileak benetan agerian uzten duen ordenan, lau erantzun posibleek lau konponketa desberdin behar dituztelako.
1. urratsa: gertatu zen bidalketa harrapatu
Ireki Sarea panela bidali aurretik, ezarri erregistroa nabigazioen artean sarrerak gordetzeko, eta egin probako bidalketa kaltegabe bat erabiltzeko baimena duzun kontu batekin. Aukeratu formularioak berak abiatutako eskaera, ez orriaren dokumentu eskaera.
Kontuz ibili iragazkiekin. XHR edo Fetch iragazkia erosoa da, baina markoak oraindik iframe ezkutu baten edo dinamikoki sortutako formulario baten bidez bidaltzen badu, iragazkiak garrantzitsua den eskaera bakarra ezkutatuko du. Bidali lehenengo iragazkirik gabe eta begiratu zer agertu den.
Aukeratutako eskaerarako, idatzi sei gauza edozer interpretatu aurretik: metodoa, URL osoa kontsulta katearekin, egoera, birbideratze katea, erantzunaren Content-Type, eta gorputzaren lehen lerroak. Chrome DevTools-en Sarea panelaren erreferentziak Headers, Response eta Initiator ikuspegietan kokatzen du hori, eta beste nabigatzaile batzuetako panel baliokideek eremu berak erakusten dituzte.
2. urratsa: egiaztatu uste duzun eskaera dela
JSON errore asko, harrigarria bada ere, bideratze erroreak dira. Bidalketa kudeatzaileak preventDefault deitu aurretik salbuespena botatzen badu, nabigatzaileak formularioaren POST natiboa egiten du action atributuak dioen helbidera, eta zerbitzariak HTML orri oso batekin erantzuten du. Kudeatzailea ez da inoiz exekutatzen, beraz ez zen JSONik eskatu.
Konparatu paneleko URL zure JavaScript-ek deitzen duen URL-arekin. Bilatu beste leku batean amaitzen den birbideratzea, falta den edo soberan dagoen amaierako barra, metodo desdoitzea kudeatzaileak GET bidaltzen duenean eta muturrak POST onartzen duenean, edo mugitu den orri batetik bide erlatibo batera bidaltzen duen formularioa. Jarraitu birbideratze katea amaieraraino eta idatzi azken URLa, ez lehenengoa.
Ondoren egiaztatu abiarazlea. Eskaera dokumentu nabigazio batetik etorri bada eta ez zure script-etik, arazoa jada aurkitu duzu, eta erantzun parser-aren edozein aldaketak ez du lagunduko.
3. urratsa: sailkatu emaitza lau kategoriatan
Emaitza bakoitza hauetako batean soilik sartzen da, eta kategoriak erabakitzen du non begiratu hurrena.
| 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 |
Erdiko errenkadak dira jendeak gaizki diagnostikatzen dituenak, egoera 200 delako. Birbideratze baten ondoren iristen den saio-hasiera orriak HTTP erantzun oso ona eta JSON dokumentu oso txarra dira. application/json eduki motak ez du hori konpontzen: etiketa bat da, eta gaizki etiketatutako gorputzak huts egiten du parseatzen. Sarbidea blokeatuta da eskaera amaituta bezala dirudien errenkada: panelak egoera erakusten du, baina jatorri gurutzatuaren politikak gorputza atxikitzen du, beraz deitzen duen script-arentzat denbora-muga bezain erabilgarria da.
Laugarren errenkada berdina da PHP eta marko pila zaharretan. Karga kodetua baino lehen inprimatutako zaharkitze abisuak inongo JSON parser-ek onartuko ez duen gorputza sortzen du, eta askotan abisu hori da azalpen osoa.
4. urratsa: irakurri parser-aren errorea hitzez hitz
Errorearen testuak parsea hautsi zuen lehen karakterearen izena ematen du, eta horrek kategoria identifikatzen du normalean inolako susmorik gabe.
| 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 |
200 batekin gorputz hutsa kasu bereizia da: muturra exekutatu zen, ezer ez zuen sortu, eta beherago zerbait arrakasta bezala hartu zuen. Aplikazio kontratuaren hutsegitea da, ez garraioarena, eta hurrengo urratsean du tokia, ez proxian. Firefox-ek eta Safari-k lau hutsegite berak beste modu batera formulatzen dituzte, beraz parekatu karakterearen edo gorputz hutsaren arabera, ez kate zehatzaren arabera.
5. urratsa: konpondu frogak seinalatzen duen geruza
Bideratze arazo baterako, konpondu eskaera: zuzendu action, eragotzi kudeatzailea erortzea, egin muturra eta metodoa bat etor daitezen, eta probatu berriro. Irudikapen arazo baterako, konpondu gorputza sortu zuena, eta jakin zergatik itzultzen den errore dokumentu bat datuak espero ziren tokian. Kontratu arazo baterako, irakurri markoaren benetako espero den egitura exekutatzen duzun bertsiorako, eta eman erantzunari forma horren arabera bezeroa lasaitzen duzun ordez.
Sarbide blokeatuko erantzunak bere pasabidea behar du, eskaera bera zuzena izan baitaiteke eta gorputza inoiz zure koderaino irits ez. Konparatu erantzunaren Access-Control-Allow-Origin nabigatzaileak bidalitako Origin zehatzarekin, eta gogoratu komodin batek ez duela kredentzialak dituen eskaera betetzen. Parekatu credentials: 'include' bezeroan Access-Control-Allow-Credentials: true zerbitzarian, eta egiaztatu deialdiak no-cors modua erabili zuen, non gorputz opakua dokumentatutako emaitza den eta ez akatsa.
Parser-a zerbait onberarekin ordezkatzea da saihestu beharreko konponketa bakarra. Erantzuna kode gisa ebaluatzea, edo testua parseatzen den arte kentzea, kontratu desdoitzea ezkutatzen du eta injekzio azalera gehitzen du isiltasunaren truke. Era berean, egoera gorputzetik bereiz egiaztatzea derrigorrezkoa da: aplikazio mailako errore objektu bat dakarren 200 arrunta da API askotan eta karga irakurriz landu behar da.
Beste norbaiten laguntza behar duzunean, partekatu erregistro minimo bat — metodoa, URLa, egoera, birbideratzeen ondorengo azken URLa, erantzunaren eduki mota, gorputzaren forma eta espero den kontratua — eta ez esportazio gordina. Sare artxiboek cookieak, tokenak, kontsulta kateak eta formularioan zeuden datu pertsonalak dituzte, eta garbitzaile automatikoa ez da berrikuspena.
- Harrapatu eskaera iragazkirik gabe edozein kode aldatu aurretik.
- Egiaztatu abiarazlea zure script-a izan zela eta azken URLa zure muturra dela.
- Sailkatu erantzuna parser-a ukitu aurretik.
- Konpondu bideratzea, sarbidea, irudikapena edo kontratua, eta inoiz ez parser-a lasaituta.