AJAX forma gaida JSON, bet saņem HTML: pārbaudiet atbildi soli pa solim
Atbilde ar statusu 200 nav pierādījums, ka tas ir JSON. Izstaigājiet tīkla paneli soli pa solim un atdaliet transporta, attēlojuma un līguma kļūdas.
Forma tiek nosūtīta, parādās ritenītis, un konsole saka, ka JSON 0 pozīcijā ir negaidīta zīme <. Pati lapa ielādējas labi, tāpēc pirmais instinkts ir vainot parsētāju vai tuneli. Parasti neviens no tiem nav iesaistīts: nosūtīšana ir cits pieprasījums nekā lapas ielāde, un tas atgriezās ar kaut ko, kas nav JSON. Strādājiet tādā secībā, kādā pārlūkprogramma to patiešām atklāj, jo četras iespējamās atbildes prasa četrus dažādus labojumus.
1. solis: noķeriet nosūtīšanu, kas patiešām notika
Atveriet tīkla paneli pirms nosūtīšanas, iestatiet žurnālu tā, lai ieraksti saglabātos starp navigācijām, un pēc tam veiciet vienu nekaitīgu testa nosūtīšanu kontā, kuru drīkstat izmantot. Izvēlieties pieprasījumu, ko iniciējusi pati forma, nevis lapas dokumenta pieprasījumu.
Uzmanieties ar filtriem. XHR vai Fetch filtrs ir ērts, taču, ja ietvars joprojām sūta caur paslēptu iframe vai dinamiski veidotu formu, filtrs paslēps vienīgo svarīgo pieprasījumu. Vispirms nosūtiet vienreiz bez filtra un paskatieties, kas parādījās.
Izvēlētajam pieprasījumam pirms jebkādas interpretācijas pierakstiet sešas lietas: metodi, pilnu URL ar vaicājuma virkni, statusu, pāradresāciju ķēdi, atbildes Content-Type un ķermeņa pirmās rindas. Chrome DevTools tīkla paneļa uzziņa aptver skatus Headers, Response un Initiator, kur tas atrodas, un citu pārlūku līdzvērtīgie paneļi rāda tos pašus laukus.
2. solis: pārliecinieties, ka tas ir tas pieprasījums
Pārsteidzoši daudz JSON kļūdu patiesībā ir maršrutēšanas kļūdas. Ja nosūtīšanas apstrādātājs izmet izņēmumu pirms preventDefault izsaukšanas, pārlūkprogramma veic formai raksturīgo POST uz adresi, kas norādīta action atribūtā, un serveris atbild ar pilnu HTML lapu. Apstrādātājs nekad neizpildās, tāpēc JSON nekad netika pieprasīts.
Salīdziniet panelī redzamo URL ar to, ko izsauc jūsu JavaScript. Meklējiet pāradresāciju, kas beidzas citur, trūkstošu vai lieku noslēguma slīpsvītru, metodes neatbilstību, kad apstrādātājs sūta GET, bet galapunkts pieņem POST, vai formu, kas sūta uz relatīvu ceļu no pārvietotas lapas. Sekojiet pāradresāciju ķēdei līdz galam un pierakstiet galīgo URL, nevis pirmo.
Pēc tam pārbaudiet iniciatoru. Ja pieprasījums nāca no dokumenta navigācijas, nevis no jūsu skripta, problēma jau ir atrasta, un nekādas izmaiņas atbildes parsētājā nepalīdzēs.
3. solis: sadaliet rezultātu četrās kategorijās
Katrs rezultāts pieder tieši vienai no tām, un kategorija nosaka, kur skatīties tālāk.
| 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 |
Vidējās rindas ir tās, ko cilvēki diagnosticē nepareizi, jo statuss ir 200. Pēc pāradresācijas sasniegta pierakstīšanās lapa ir pilnīgi laba HTTP atbilde un ļoti slikts JSON dokuments. Satura tips application/json to nesalabo: tas ir tikai birka, un nepareizi marķēts ķermenis joprojām neparsējas. Piekļuve bloķēta ir rinda, kas izskatās kā pabeigts pieprasījums: panelis rāda statusu, bet starpizcelsmes politika aiztur ķermeni, tāpēc izsaucošajam skriptam tas ir tikpat neizmantojams kā taimauts.
Ceturtā rinda ir tikpat izplatīta vecākos PHP un ietvaru krājumos. Pirms kodētās kravas izdrukāts novecošanas brīdinājums rada ķermeni, ko nepieņems neviens JSON parsētājs, un bieži vien šis brīdinājums ir viss skaidrojums.
4. solis: lasiet parsētāja kļūdu burtiski
Kļūdas teksts nosauc pirmo rakstzīmi, kas salauza parsēšanu, un tas parasti identificē kategoriju bez jebkādām minējumiem.
| 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 |
Tukšs ķermenis ar 200 ir atsevišķs gadījums: galapunkts darbojās, neko neizstrādāja, un kaut kas lejāk to uztvēra kā panākumu. Tas ir lietotnes līguma, nevis transporta bojājums, un tā vieta ir nākamajā solī, nevis starpniekā. Firefox un Safari tos pašus četrus bojājumus formulē citādi, tāpēc salīdziniet pēc rakstzīmes vai tukša ķermeņa, nevis pēc precīzas virknes.
5. solis: izlabojiet slāni, uz kuru norāda pierādījumi
Ja problēma ir maršrutēšanā, labojiet pieprasījumu: izlabojiet action, neļaujiet apstrādātājam izkrist, saskaņojiet galapunktu un metodi un pārbaudiet vēlreiz. Ja problēma ir attēlojumā, labojiet to, kas radīja ķermeni, un noskaidrojiet, kāpēc kļūdas dokuments tiek atgriezts tur, kur tika gaidīti dati. Ja problēma ir līgumā, izlasiet ietvara faktisko gaidīto struktūru jūsu izpildītajai versijai un veidojiet atbildi atbilstoši tai, nevis atslābiniet klientu.
Atbilde ar bloķētu piekļuvi prasa savu gājienu, jo pats pieprasījums var būt pareizs un ķermenis var nekad nesasniegt jūsu kodu. Salīdziniet atbildes Access-Control-Allow-Origin ar precīzo Origin, ko nosūtīja pārlūkprogramma, un atcerieties, ka aizstājējzīme neapmierina pieprasījumu ar akreditācijas datiem. Savienojiet pāros credentials: 'include' klientā ar Access-Control-Allow-Credentials: true serverī un pārbaudiet, vai izsaukums neizmantoja no-cors režīmu, kur necaurredzams ķermenis ir dokumentēts rezultāts, nevis defekts.
Aizstāt parsētāju ar kaut ko piekāpīgāku ir vienīgais labojums, no kura jāizvairās. Atbildes novērtēšana kā kods vai teksta nolobīšana, līdz tā parsējas, slēpj līguma neatbilstību un pretī klusumam pievieno injekcijas virsmu. Tāpat statuss jāpārbauda atsevišķi no ķermeņa: 200 ar lietotnes līmeņa kļūdas objektu ir normāli daudzos API un tas jāapstrādā, lasot kravu.
Kad vajadzīga cita cilvēka palīdzība, kopīgojiet minimālu ierakstu — metode, URL, statuss, galīgais URL pēc pāradresācijām, atbildes satura tips, ķermeņa forma un gaidītais līgums — nevis neapstrādātu eksportu. Tīkla arhīvos ir sīkfaili, marķieri, vaicājuma virknes un personas dati, kas bija formā, un automātisks tīrītājs nav pārskatīšana.
- Noķeriet pieprasījumu bez filtra pirms jebkāda koda maiņas.
- Pārliecinieties, ka iniciators bija jūsu skripts un galīgais URL ir jūsu galapunkts.
- Klasificējiet atbildi pirms parsētāja aizskaršanas.
- Labojiet maršrutēšanu, piekļuvi, attēlojumu vai līgumu un nekad atslābinot parsētāju.