Borang AJAX menjangka JSON tetapi menerima HTML: telusuri respons langkah demi langkah
Respons 200 bukan bukti ia JSON. Telusuri panel Rangkaian langkah demi langkah dan asingkan kegagalan pengangkutan, perwakilan dan kontrak.
Borang dihantar, pemutar muncul dan konsol berkata terdapat token < tidak dijangka dalam JSON pada kedudukan 0. Halaman itu sendiri dimuat dengan baik, sebab itu naluri pertama ialah menyalahkan penghurai atau terowong. Biasanya kedua-duanya tidak terlibat: penghantaran ialah permintaan berbeza daripada pemuatan halaman, dan ia kembali dengan sesuatu yang bukan JSON. Bekerja mengikut urutan yang benar-benar didedahkan pelayar, kerana empat jawapan yang mungkin memerlukan empat pembetulan berbeza.
Langkah 1: tangkap penghantaran yang benar-benar berlaku
Buka panel Rangkaian sebelum menghantar, tetapkan log untuk mengekalkan entri merentas navigasi, kemudian buat satu penghantaran ujian tidak berbahaya pada akaun yang anda dibenarkan gunakan. Pilih permintaan yang dimulakan oleh borang itu sendiri, bukan permintaan dokumen halaman.
Berhati-hati dengan penapis. Penapis XHR atau Fetch mudah, tetapi jika rangka kerja masih menghantar melalui iframe tersembunyi atau borang yang dicipta secara dinamik, penapis akan menyembunyikan satu-satunya permintaan yang penting. Hantar sekali tanpa penapis dahulu dan lihat apa yang muncul.
Untuk permintaan yang dipilih, catat enam perkara sebelum sebarang tafsiran: kaedah, URL penuh termasuk rentetan pertanyaan, status, rantaian ubah hala, Content-Type respons dan baris pertama badan. Rujukan panel Rangkaian Chrome DevTools merangkumi paparan Headers, Response dan Initiator tempat perkara itu berada, dan panel setara dalam pelayar lain menunjukkan medan yang sama.
Langkah 2: sahkan ia permintaan yang anda maksudkan
Bilangan ralat JSON yang mengejutkan sebenarnya ralat penghalaan. Jika pengendali penghantaran melontar pengecualian sebelum memanggil preventDefault, pelayar melakukan POST borang asli ke alamat yang dinyatakan atribut action, dan pelayan menjawab dengan halaman HTML penuh. Pengendali tidak pernah berjalan, jadi JSON tidak pernah diminta.
Bandingkan URL dalam panel dengan URL yang dipanggil JavaScript anda. Cari ubah hala yang berakhir di tempat lain, garis miring akhir yang hilang atau berlebihan, ketidakpadanan kaedah apabila pengendali menghantar GET dan titik akhir menerima POST, atau borang yang menghantar ke laluan relatif dari halaman yang telah berpindah. Ikuti rantaian ubah hala hingga akhir dan catat URL terakhir, bukan yang pertama.
Kemudian periksa pemula. Jika permintaan datang dari navigasi dokumen dan bukan daripada skrip anda, anda sudah menemui masalahnya, dan tiada perubahan pada penghurai respons akan membantu.
Langkah 3: kelaskan hasil kepada empat kategori
Setiap hasil tergolong tepat dalam salah satu daripada ini, dan kategori menentukan ke mana anda melihat seterusnya.
| 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 |
Baris tengah ialah yang salah didiagnosis, kerana statusnya 200. Halaman log masuk yang dicapai selepas ubah hala ialah respons HTTP yang sangat baik dan dokumen JSON yang sangat buruk. Jenis kandungan application/json tidak membaikinya: ia label, dan badan yang salah label masih gagal dihurai. Akses disekat ialah baris yang kelihatan seperti permintaan selesai: panel menunjukkan status, tetapi dasar merentas asal menahan badan, jadi bagi skrip yang memanggil ia sama tidak berguna seperti had masa.
Baris keempat sama biasa pada tindanan PHP dan rangka kerja lama. Amaran penghentian penggunaan yang dicetak sebelum muatan dikodkan menghasilkan badan yang tidak akan diterima mana-mana penghurai JSON, dan sering amaran itu ialah keseluruhan penjelasan.
Langkah 4: baca ralat penghurai secara literal
Teks ralat menamakan aksara pertama yang memecahkan penghuraian, dan itu biasanya mengenal pasti kategori tanpa tekaan.
| 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 |
Badan kosong dengan 200 ialah kes tersendiri: titik akhir berjalan, tidak menghasilkan apa-apa, dan sesuatu di hilir menganggapnya berjaya. Itu kegagalan kontrak aplikasi, bukan pengangkutan, dan tempatnya di langkah seterusnya, bukan dalam proksi. Firefox dan Safari merumuskan empat kegagalan yang sama secara berbeza, jadi padankan pada aksara atau badan kosong, bukan pada rentetan tepat.
Langkah 5: betulkan lapisan yang ditunjuk bukti
Untuk masalah penghalaan, betulkan permintaan: betulkan action, halang pengendali daripada jatuh, selaraskan titik akhir dan kaedah, dan uji semula. Untuk masalah perwakilan, betulkan apa yang menghasilkan badan, dan ketahui mengapa dokumen ralat dikembalikan di tempat data dijangka. Untuk masalah kontrak, baca struktur sebenar yang dijangkakan rangka kerja untuk versi yang anda jalankan, dan bentuk respons mengikutnya daripada melonggarkan klien.
Respons dengan akses disekat memerlukan pusingan tersendiri, kerana permintaan itu sendiri mungkin betul dan badan mungkin tidak pernah sampai ke kod anda. Bandingkan Access-Control-Allow-Origin respons dengan Origin tepat yang dihantar pelayar, dan ingat bahawa kad liar tidak memenuhi permintaan dengan kelayakan. Pasangkan credentials: 'include' pada klien dengan Access-Control-Allow-Credentials: true pada pelayan, dan periksa sama ada panggilan menggunakan mod no-cors, tempat badan legap ialah hasil berdokumen dan bukan kecacatan.
Menggantikan penghurai dengan sesuatu yang lebih longgar ialah satu-satunya pembetulan yang perlu dielakkan. Menilai respons sebagai kod, atau mengupas teks sehingga ia dihurai, menyembunyikan ketidakpadanan kontrak dan menambah permukaan suntikan sebagai pertukaran untuk kesunyian. Begitu juga, menyemak status secara berasingan daripada badan adalah wajib: 200 yang membawa objek ralat peringkat aplikasi adalah normal dalam banyak API dan mesti dikendalikan dengan membaca muatan.
Apabila anda memerlukan bantuan orang lain, kongsi rekod minimum — kaedah, URL, status, URL akhir selepas ubah hala, jenis kandungan respons, bentuk badan dan kontrak yang dijangkakan — dan bukan eksport mentah. Arkib rangkaian mengandungi kuki, token, rentetan pertanyaan dan data peribadi yang ada dalam borang, dan pembersih automatik bukan semakan.
- Tangkap permintaan tanpa penapis sebelum menukar mana-mana kod.
- Sahkan pemula ialah skrip anda dan URL akhir ialah titik akhir anda.
- Kelaskan respons sebelum menyentuh penghurai.
- Betulkan penghalaan, akses, perwakilan atau kontrak, dan jangan sekali-kali dengan melonggarkan penghurai.