Apakah kode Status HTTP 0 memiliki arti?

Tampaknya saat Anda membuat XMLHttpRequest dari skrip di browser, jika browser disetel untuk bekerja offline atau jika kabel jaringan dicabut, permintaan selesai dengan kesalahan dan dengan status = 0. 0 tidak terdaftar di antara yang diizinkan Kode status HTTP.

Apa arti kode status 0? Apakah ini berarti hal yang sama di semua browser, dan untuk semua utilitas klien HTTP? Apakah ini bagian dari spesifikasi HTTP atau bagian dari beberapa spesifikasi protokol lain? Tampaknya permintaan HTTP tidak dapat dibuat sama sekali, mungkin karena alamat server tidak dapat diselesaikan.

Pesan kesalahan apa yang tepat untuk ditampilkan kepada pengguna? "Anda tidak tersambung ke internet, atau situs web mengalami masalah, atau mungkin ada kesalahan pengetikan pada alamat"?

Saya harus menambahkan ini bahwa saya melihat perilaku di FireFox ketika diatur ke "Bekerja Offline", tetapi tidak di Microsoft Internet Explorer ketika diatur ke "Bekerja Offline". Di IE, pengguna mendapatkan dialog yang memberikan opsi untuk online. FireFox tidak memberi tahu pengguna sebelum mengembalikan kesalahan.

Saya menanyakan ini sebagai tanggapan atas permintaan untuk "menampilkan pesan kesalahan yang lebih baik". Apa yang dilakukan Internet Explorer itu bagus. Ini memberi tahu pengguna apa yang menyebabkan masalah dan memberi mereka opsi untuk memperbaikinya. Untuk memberikan UX yang setara dengan FireFox, saya perlu menyimpulkan penyebab masalah dan memberi tahu pengguna. Jadi, apa total yang dapat saya simpulkan dari Status 0? Apakah itu memiliki makna universal atau tidak memberi tahu saya apa-apa?

Jawaban singkat

Ini bukan kode respons HTTP, tetapi didokumentasikan oleh WhatWG sebagai nilai yang valid untuk atribut status file XMLHttpRequest atau respons Ambil.

Secara umum, ini adalah nilai default yang digunakan ketika tidak ada kode status HTTP nyata untuk dilaporkan dan / atau kesalahan terjadi saat mengirim permintaan atau menerima respons. Skenario yang mungkin terjadi termasuk, tetapi tidak terbatas pada:

• Permintaan belum dikirim, atau telah dibatalkan.
• Browser masih menunggu untuk menerima status dan header tanggapan.
• Koneksi terputus selama permintaan.
• Waktu permintaan habis.
• Permintaan tersebut mengalami loop pengalihan tak terbatas.
• Browser mengetahui status respons, tetapi Anda tidak diizinkan untuk mengaksesnya karena batasan keamanan terkait dengan Kebijakan Asal yang Sama .

Jawaban panjang

Pertama, untuk mengulangi: 0 bukanlah kode status HTTP. Ada daftar lengkapnya di RFC 7231 Bagian 6.1 , yang tidak menyertakan 0, dan pengantar ke bagian 6 menyatakan dengan jelas bahwa

Elemen kode status adalah kode integer tiga digit

mana yang bukan 0.

Namun, 0 sebagai nilai .statusatribut objek XMLHttpRequest didokumentasikan, meskipun agak sulit untuk melacak semua detail yang relevan. Kami mulai di https://xhr.spec.whatwg.org/#the-status-attribute , mendokumentasikan .statusatribut, yang hanya menyatakan:

The statusatribut harus mengembalikan respon ‘s statusnya .

Kedengarannya hampa dan tautologis, tetapi kenyataannya ada informasi di sini! Ingatlah bahwa dokumentasi ini berbicara di sini tentang .responseatribut dari XMLHttpRequest, bukan respons, jadi ini memberi tahu kita bahwa definisi status pada objek XHR ditangguhkan ke definisi status respons dalam spesifikasi Ambil.

Tapi objek respon apa? Bagaimana jika kita belum benar-benar menerima tanggapan? Tautan sebaris pada kata "respons" membawa kita ke https://xhr.spec.whatwg.org/#response , yang menjelaskan:

An XMLHttpRequestmemiliki tanggapan terkait. Kecuali dinyatakan sebaliknya, itu adalah kesalahan jaringan .

Jadi respons yang statusnya kami dapatkan secara default adalah kesalahan jaringan. Dan dengan menelusuri di mana pun frasa "set response to" digunakan dalam spesifikasi XHR, kita dapat melihat bahwa frasa tersebut disetel di lima tempat:

• Untuk kesalahan jaringan, ketika:

  • yang open()metode disebut, atau
  • respon ini tubuh 's aliran yang errored (lihat algoritma yang dijelaskan dalam dokumentasi untuk para send()metode )
  • yang timed out bendera diatur, menyebabkan langkah permintaan kesalahan untuk menjalankan
  • yang abort()metode disebut, menyebabkan langkah permintaan kesalahan untuk menjalankan

• Untuk respons yang dihasilkan dengan mengirimkan permintaan menggunakan Fetch, baik melalui tugas respons proses Fetch (jika permintaan XHR adalah asikron) atau tugas akhir tubuh respons proses Fetch (jika permintaan XHR sinkron).

Melihat dalam standar Fetch , kita dapat melihat bahwa:

Sebuah kesalahan jaringan adalah respon yang statusnya selalu0

sehingga kita dapat segera mengetahui bahwa kita akan melihat status 0 pada objek XHR dalam setiap kasus di mana spesifikasi XHR mengatakan bahwa respons harus disetel ke kesalahan jaringan. (Menariknya, ini termasuk kasus di mana aliran tubuh mendapat "kesalahan", yang menurut spesifikasi Ambil dapat terjadi selama penguraian tubuh setelah menerima status - jadi secara teori saya rasa mungkin saja objek XHR memiliki statusnya setel ke 200, lalu temukan kesalahan kehabisan memori atau sesuatu saat menerima isi dan ubah statusnya kembali ke 0.)

Kami juga mencatat dalam standar Ambil bahwa ada beberapa jenis respons lain yang statusnya ditentukan sebagai 0, yang keberadaannya terkait dengan permintaan lintas sumber dan kebijakan asal yang sama:

Respons yang difilter buram adalah respons yang difilter yang ... statusnya adalah 0...

Respons terfilter pengalihan buram adalah respons yang difilter yang ... statusnya adalah 0...

(berbagai detail lain tentang kedua jenis respons ini dihilangkan).

Namun di luar ini, ada juga banyak kasus di mana algoritme Ambil (daripada spesifikasi XHR, yang telah kita lihat) meminta browser untuk mengembalikan kesalahan jaringan! Memang, frase "mengembalikan kesalahan jaringan" muncul 40 kali dalam standar Ambil. Saya tidak akan mencoba mencantumkan semua 40 di sini, tetapi saya perhatikan bahwa mereka termasuk:

• Kasus di mana skema permintaan tidak dikenali (misalnya mencoba mengirim permintaan ke madeupscheme: //foobar.com)
• Instruksi yang sangat tidak jelas "Jika ragu, kembalikan kesalahan jaringan." dalam algoritme untuk menangani URL ftp: // dan file: //
• Pengalihan tak terbatas: "Jika jumlah pengalihan permintaan dua puluh, kembalikan kesalahan jaringan."
• Sekumpulan masalah terkait CORS, seperti "Jika httpRequest respon tainting bukan" cors "dan pemeriksaan kebijakan sumber daya lintas sumber dengan permintaan dan respon kembali diblokir, kemudian mengembalikan kesalahan jaringan."
• Kegagalan koneksi: "Jika koneksi gagal, kembalikan kesalahan jaringan."

Dengan kata lain: setiap kali ada sesuatu yang tidak beres lain daripada mendapatkan HTTP nyata kode status kesalahan seperti 500 atau 400 dari server, Anda berakhir dengan atribut status 0 pada objek XHR Anda atau Ambil objek respon dalam browser. Jumlah kemungkinan penyebab spesifik yang disebutkan dalam spesifikasi sangat banyak.

Terakhir: jika Anda tertarik dengan riwayat spesifikasi karena suatu alasan, perhatikan bahwa jawaban ini telah sepenuhnya ditulis ulang pada tahun 2020, dan Anda mungkin tertarik dengan revisi sebelumnya dari jawaban ini , yang pada dasarnya mengurai kesimpulan yang sama dari spesifikasi W3 yang lebih tua (dan lebih sederhana) untuk XHR, sebelum ini digantikan oleh spesifikasi WhatWG yang lebih modern dan lebih rumit yang dirujuk oleh jawaban ini.

status 0 muncul ketika panggilan ajax dibatalkan sebelum mendapatkan respons dengan menyegarkan halaman atau meminta URL yang tidak dapat dijangkau.

status ini tidak didokumentasikan tetapi ada melalui ajax dan panggilan makeRequest dari gadget.io.

dari dokumentasi http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute berarti permintaan dibatalkan sebelum pergi ke mana pun

Ketahuilah bahwa ini adalah postingan lama. Tapi masalah ini masih ada.

Berikut adalah beberapa temuan saya tentang masalah ini, dijelaskan secara kasar.

"Status" 0 berarti salah satu dari 3 hal, sesuai dengan spesifikasi XMLHttpRequest:

• Resolusi nama dns gagal (itu misalnya ketika steker jaringan dicabut)

• server tidak menjawab (alias tidak dapat dijangkau atau tidak merespons)

• permintaan dibatalkan karena masalah CORS (aborsi dilakukan oleh agen pengguna dan mengikuti OPTIONS pra-penerbangan yang gagal).

Jika Anda ingin melangkah lebih jauh, selami lebih dalam di dalam XMLHttpRequest. Saya sarankan membaca urutan update keadaan siap ([0,1,2,3,4] adalah urutan normal, [0,1,4] sesuai dengan status 0, [0,1,2,4] berarti tidak ada konten terkirim yang mungkin merupakan kesalahan atau tidak). Anda mungkin juga ingin melampirkan listener ke xhr (onreadystatechange, onabort, onerror, ontimeout) untuk mengetahui detailnya.

Dari spesifikasi (spesifikasi XHR Living ):

const unsigned short UNSENT = 0;
const unsigned short OPENED = 1;
const unsigned short HEADERS_RECEIVED = 2;
const unsigned short LOADING = 3;
const unsigned short DONE = 4;

Sejak iOS 9, Anda perlu menambahkan "App Transport Security Settings" ke file info.plist Anda dan mengizinkan "Allow Arbitrary Loads" sebelum membuat permintaan ke layanan web HTTP yang tidak aman. Saya mengalami masalah ini di salah satu aplikasi saya.

Ya, beberapa cara panggilan ajax dibatalkan. Penyebabnya mungkin berikut.

1. Sebelum menyelesaikan permintaan ajax, pengguna membuka halaman lain.
2. Permintaan Ajax memiliki waktu tunggu.
3. Server tidak dapat memberikan tanggapan apa pun.