Ajax-formularo atendas JSON sed ricevas HTML: sekvu la respondon paŝon post paŝo
Respondo 200 ne pruvas, ke temas pri JSON. Trairu la retpanelon paŝon post paŝo kaj apartigu misfunkciojn de transporto, prezentado kaj kontrakto.
La formularo estas sendata, la ŝpinilo aperas, kaj la konzolo diras neatenditan signon < en JSON ĉe pozicio 0. La paĝo mem ŝargiĝas bone, do la unua instinkto estas kulpigi la analizilon aŭ la tunelon. Kutime nek unu nek la alia partoprenas: la sendado estas alia peto ol la ŝargado de la paĝo, kaj ĝi revenis kun io, kio ne estas JSON. Laboru laŭ la ordo, en kiu la retumilo efektive malkaŝas ĝin, ĉar la kvar eblaj respondoj postulas kvar malsamajn korektojn.
Paŝo 1: kaptu la sendadon, kiu vere okazis
Malfermu la retpanelon antaŭ ol sendi, agordu la protokolon por konservi rikordojn trans navigado, kaj poste faru unu sendangeran testan sendadon per konto, kiun vi rajtas uzi. Elektu la peton, kiun iniciatis la formularo mem, ne la dokumentpeton de la paĝo.
Estu singarda pri filtriloj. Filtrilo XHR aŭ Fetch estas oportuna, sed se la kadro ankoraŭ sendas per kaŝita iframe aŭ dinamike kreita formularo, la filtrilo kaŝos la solan peton, kiu gravas. Sendu unue unufoje sen filtrilo kaj rigardu, kio aperis.
Por la elektita peto notu ses aferojn antaŭ ol interpreti ion ajn: la metodon, la plenan URL kun la konsulta ĉeno, la staton, la plusendan ĉenon, la Content-Type de la respondo, kaj la unuajn liniojn de la korpo. La referenco pri la retpanel o de Chrome DevTools kovras la vidojn Headers, Response kaj Initiator, kie tiuj troviĝas, kaj la ekvivalentaj paneloj en aliaj retumiloj montras la samajn kampojn.
Paŝo 2: konfirmu, ke temas pri la peto, kiun vi pensas
Surprize multaj JSON-eraroj estas fakte enkursigaj eraroj. Se la senda traktilo ĵetas escepton antaŭ ol ĝi vokas preventDefault, la retumilo faras denaskan formularan POST al tio, kion diras la atributo action, kaj la servilo respondas per plena HTML-paĝo. La traktilo neniam ruliĝas, do JSON neniam estis petita.
Komparu la URL en la panelo kun la URL, kiun vokas via JavaScript. Serĉu plusendon, kiu finiĝas aliloke, mankantan aŭ superfluan finan oblikvon, malkongruon de metodo, kie la traktilo sendas GET kaj la finpunkto akceptas POST, aŭ formularon sendantan al relativa vojo de paĝo, kiu moviĝis. Sekvu la plusendan ĉenon ĝis la fino kaj notu la finan URL, ne la unuan.
Poste kontrolu la iniciatinton. Se la peto venis el dokumenta navigado anstataŭ el via skripto, vi jam trovis la problemon, kaj neniu ŝanĝo al responda analizilo helpos.
Paŝo 3: ordigu la rezulton en kvar kategoriojn
Ĉiu rezulto apartenas al ekzakte unu el ĉi tiuj, kaj la kategorio decidas, kien rigardi poste.
| 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 |
La mezaj vicoj estas tiuj, kiujn homoj misdiagnozas, ĉar la stato estas 200. Ensaluta paĝo atingita post plusendo estas tute bona HTTP-respondo kaj tre malbona JSON-dokumento. La enhavtipo application/json ne riparas tion: ĝi estas etikedo, kaj mise etikedita korpo ankoraŭ malsukcesas analiziĝi. Aliro blokita estas la vico, kiu aspektas kiel finita peto: la panelo montras staton, sed la transdevena politiko retenas la korpon, do por la vokanta skripto ĝi estas same neuzebla kiel tempolimo.
La kvara vico estas egale ofta en pli malnovaj PHP- kaj kadraj stokoj. Malmoderniga averto presita antaŭ la kodigita ŝarĝo produktas korpon, kiun neniu JSON-analizilo akceptos, kaj ofte tiu averto estas la tuta klarigo.
Paŝo 4: legu la analizilan eraron laŭvorte
La erarteksto nomas la unuan signon, kiu rompis la analizon, kaj tio kutime identigas la kategorion sen ia divenado.
| 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 |
Malplena korpo kun 200 estas propra kazo: la finpunkto ruliĝis, produktis nenion, kaj io pli malsupre traktis tion kiel sukceson. Tio estas malsukceso de aplikaĵa kontrakto, ne de transporto, kaj ĝi apartenas al la sekva paŝo, ne al la prokurilo. Firefox kaj Safari esprimas la samajn kvar malsukcesojn alimaniere, do kongruigu laŭ la signo aŭ la malplena korpo, ne laŭ la ekzakta ĉeno.
Paŝo 5: ripari la tavolon, al kiu montras la pruvoj
Por enkursiga problemo ripari la peton: korektu la action, malhelpu la traktilon fali tra, kongruigu finpunkton kaj metodon, kaj retestu. Por prezentada problemo ripari tion, kio produktis la korpon, kaj eltrovu, kial erardokumento revenas tie, kie datumoj estis atenditaj. Por kontrakta problemo legu la efektivan atendatan strukturon de la kadro por la versio, kiun vi rulas, kaj formu la respondon laŭ ĝi anstataŭ malstreĉi la klienton.
Respondo kun blokita aliro bezonas propran trairon, ĉar la peto mem povas esti ĝusta kaj la korpo eble neniam atingos vian kodon. Komparu la Access-Control-Allow-Origin de la respondo kun la ekzakta Origin, kiun la retumilo sendis, kaj memoru, ke ĵokero ne kontentigas peton kun legitimiloj. Parigu credentials: 'include' en la kliento kun Access-Control-Allow-Credentials: true en la servilo, kaj kontrolu, ĉu la voko uzis reĝimon no-cors, kie netravidebla korpo estas dokumentita rezulto, ne cimo.
Anstataŭigi la analizilon per io pli indulgema estas la sola korekto, kiun oni devas eviti. Taksi la respondon kiel kodon, aŭ senŝeligi tekston ĝis ĝi analiziĝas, kaŝas la kontraktan malkongruon kaj aldonas surfacon por enĵeto kontraŭ silento. Same, kontroli la staton aparte de la korpo estas necesa: 200 kun erarobjekto je aplikaĵa nivelo estas normala en multaj API-oj kaj devas esti traktata legante la ŝarĝon.
Kiam vi bezonas helpon de iu alia, dividu minimuman rikordon — metodo, URL, stato, fina URL post plusendoj, enhavtipo de la respondo, formo de la korpo, kaj la atendata kontrakto — anstataŭ kruda eksportaĵo. Retaj arkivoj enhavas kuketojn, ĵetonojn, konsultajn ĉenojn kaj la personajn datumojn, kiuj estis en la formularo, kaj aŭtomata purigilo ne estas revizio.
- Kaptu la peton sen filtrilo antaŭ ol ŝanĝi ajnan kodon.
- Konfirmu, ke la iniciatinto estis via skripto kaj la fina URL estas via finpunkto.
- Klasifiku la respondon antaŭ ol tuŝi la analizilon.
- Riparu enkursigon, aliron, prezentadon aŭ kontrakton, kaj neniam malstreĉante la analizilon.