รหัสสถานะ HTTP เป็น 0 มีความหมายหรือไม่?

ดูเหมือนว่าเมื่อคุณสร้าง XMLHttpRequest จากสคริปต์ในเบราว์เซอร์หากเบราว์เซอร์ถูกตั้งค่าให้ทำงานแบบออฟไลน์หรือหากดึงสายเคเบิลเครือข่ายออกคำขอจะเสร็จสมบูรณ์โดยมีข้อผิดพลาดและมีสถานะ = 0 0 ไม่อยู่ในรายการที่อนุญาต รหัสสถานะ HTTP

รหัสสถานะ 0 หมายถึงอะไร? มันหมายถึงสิ่งเดียวกันในทุกเบราว์เซอร์และสำหรับยูทิลิตี้ไคลเอ็นต์ HTTP ทั้งหมดหรือไม่ เป็นส่วนหนึ่งของข้อมูลจำเพาะ HTTP หรือเป็นส่วนหนึ่งของข้อกำหนดโปรโตคอลอื่น ๆ หรือไม่ ดูเหมือนว่าจะหมายความว่าไม่สามารถส่งคำขอ HTTP ได้เลยบางทีอาจเป็นเพราะไม่สามารถแก้ไขที่อยู่เซิร์ฟเวอร์ได้

ข้อความแสดงข้อผิดพลาดใดเหมาะสมที่จะแสดงให้ผู้ใช้เห็น "คุณไม่ได้เชื่อมต่ออินเทอร์เน็ตหรือเว็บไซต์กำลังประสบปัญหาหรืออาจมีข้อผิดพลาดในการพิมพ์ที่อยู่"?

ฉันควรเพิ่มสิ่งนี้เพื่อที่ฉันจะเห็นพฤติกรรมใน FireFox เมื่อตั้งค่าเป็น "ทำงานออฟไลน์" แต่ไม่ใช่ใน Microsoft Internet Explorer เมื่อตั้งค่าเป็น "ทำงานออฟไลน์" ใน IE ผู้ใช้จะได้รับกล่องโต้ตอบที่ให้ตัวเลือกในการออนไลน์ FireFox ไม่แจ้งผู้ใช้ก่อนส่งคืนข้อผิดพลาด

ฉันขอสิ่งนี้เพื่อตอบสนองต่อคำขอให้ "แสดงข้อความแสดงข้อผิดพลาดที่ดีกว่า" สิ่งที่ Internet Explorer ทำได้ดี จะบอกผู้ใช้ว่าอะไรเป็นสาเหตุของปัญหาและให้ทางเลือกในการแก้ไขแก่ผู้ใช้ ในการให้ UX ที่เทียบเท่ากับ FireFox ฉันจำเป็นต้องสรุปสาเหตุของปัญหาและแจ้งให้ผู้ใช้ทราบ แล้วฉันจะสรุปอะไรได้บ้างจากสถานะ 0? มันมีความหมายสากลหรือเปล่า?

คำตอบสั้น ๆ

ไม่ใช่รหัสตอบกลับ HTTP แต่มีการจัดทำเอกสารโดย WhatWG เป็นค่าที่ถูกต้องสำหรับแอตทริบิวต์สถานะของการXMLHttpRequestตอบกลับหรือการดึงข้อมูล

โดยทั่วไปแล้วค่านี้เป็นค่าเริ่มต้นที่ใช้เมื่อไม่มีรหัสสถานะ HTTP จริงที่จะรายงานและ / หรือเกิดข้อผิดพลาดในการส่งคำขอหรือรับการตอบกลับ สถานการณ์ที่เป็นไปได้ในกรณีนี้รวมถึง แต่ไม่ จำกัด เฉพาะ:

• ยังไม่ได้ส่งคำขอหรือถูกยกเลิก
• เบราว์เซอร์ยังคงรอรับสถานะการตอบกลับและส่วนหัว
• การเชื่อมต่อหลุดระหว่างการร้องขอ
• คำขอหมดเวลา
• คำขอพบการวนรอบการเปลี่ยนเส้นทางที่ไม่สิ้นสุด
• เบราว์เซอร์ทราบสถานะการตอบสนอง แต่คุณไม่ได้รับอนุญาตให้เข้าถึงเนื่องจากข้อ จำกัด ด้านความปลอดภัยที่เกี่ยวข้องกับนโยบายแหล่งกำเนิดเดียวกัน

คำตอบยาว

ก่อนอื่นขอย้ำอีกครั้งว่า 0 ไม่ใช่รหัสสถานะ HTTP มีรายชื่อทั้งหมดในRFC 7231 ส่วน 6.1ซึ่งไม่รวม 0 และบทนำของส่วน 6 ระบุไว้อย่างชัดเจนว่า

องค์ประกอบรหัสสถานะคือรหัสจำนวนเต็มสามหลัก

ซึ่ง 0 ไม่ใช่

อย่างไรก็ตาม 0 เป็นค่าของ.statusแอตทริบิวต์ของวัตถุ XMLHttpRequest จะได้รับการจัดทำเป็นเอกสารแม้ว่าจะเป็นเรื่องยุ่งยากเล็กน้อยในการติดตามรายละเอียดที่เกี่ยวข้องทั้งหมด เราเริ่มต้นที่https://xhr.spec.whatwg.org/#the-status-attributeโดยจัดทำเอกสาร.statusแอตทริบิวต์ซึ่งระบุเพียง:

statusแอตทริบิวต์ต้องกลับมาตอบสนอง ‘s สถานะ

นั่นอาจฟังดูไร้สาระและน่าเบื่อ แต่ในความเป็นจริงมีข้อมูลอยู่ที่นี่! โปรดจำไว้ว่าเอกสารนี้กำลังพูดถึง.responseแอตทริบิวต์ของ an XMLHttpRequestไม่ใช่คำตอบดังนั้นสิ่งนี้จะบอกเราว่าคำจำกัดความของสถานะบนวัตถุ XHR จะเลื่อนไปตามคำจำกัดความของสถานะการตอบกลับในข้อมูลจำเพาะการดึงข้อมูล

แต่สิ่งที่ตอบสนองวัตถุ? จะเป็นอย่างไรหากเรายังไม่ได้รับคำตอบ ลิงก์แบบอินไลน์ของคำว่า "response" นำเราไปที่https://xhr.spec.whatwg.org/#responseซึ่งอธิบายว่า:

XMLHttpRequestมีการตอบสนองที่เกี่ยวข้อง เว้นแต่จะระบุไว้เป็นอย่างอื่นมันเป็นความผิดพลาดของเครือข่าย

ดังนั้นการตอบสนองของสถานะที่เราได้รับจึงเป็นข้อผิดพลาดของเครือข่ายโดยค่าเริ่มต้น และจากการค้นหาทุกที่ที่มีการใช้วลี"set response to"ในข้อมูลจำเพาะ XHR เราจะเห็นว่ามีการตั้งค่าไว้ใน 5 ตำแหน่ง:

• สำหรับข้อผิดพลาดของเครือข่ายเมื่อ:

  • open()วิธีการที่เรียกว่าหรือ
  • การตอบสนองของร่างกายของสตรีมจะerrored (ดูขั้นตอนวิธีการที่อธิบายไว้ในเอกสารสำหรับวิธีการ )send()
  • มีการตั้งค่าสถานะหมดเวลาทำให้ขั้นตอนข้อผิดพลาดการร้องขอทำงาน
  • มีabort()การเรียกเมธอดทำให้ขั้นตอนข้อผิดพลาดการร้องขอทำงาน

• ไปยังการตอบกลับที่สร้างขึ้นโดยการส่งคำขอโดยใช้ Fetch โดยใช้งานการตอบสนองของกระบวนการ Fetch (ถ้าคำขอ XHR เป็นแบบอะซิงโครนัส) หรืองานสิ้นสุดการตอบสนองของกระบวนการ Fetch (ถ้าคำขอ XHR เป็นแบบซิงโครนัส)

เมื่อดูในมาตรฐานการดึงข้อมูลเราจะเห็นว่า:

ข้อผิดพลาดของเครือข่ายคือการตอบสนองที่มีสถานะอยู่เสมอ0

ดังนั้นเราจึงสามารถบอกได้ทันทีว่าเราจะเห็นสถานะเป็น 0 บนวัตถุ XHR ในกรณีใด ๆ ที่ข้อมูลจำเพาะ XHR ระบุว่าควรตั้งค่าการตอบกลับเป็นข้อผิดพลาดของเครือข่าย (ที่น่าสนใจนี้รวมถึงกรณีที่กระแสของร่างกาย "ผิดพลาด" ซึ่งข้อมูลจำเพาะของ Fetch บอกเราว่าสามารถเกิดขึ้นได้ระหว่างการแยกวิเคราะห์ร่างกายหลังจากได้รับสถานะดังนั้นในทางทฤษฎีฉันคิดว่าเป็นไปได้ที่วัตถุ XHR จะมีสถานะ ตั้งค่าเป็น 200 จากนั้นพบข้อผิดพลาดหน่วยความจำไม่เพียงพอหรือบางสิ่งบางอย่างขณะรับร่างกายจึงเปลี่ยนสถานะกลับเป็น 0)

นอกจากนี้เรายังทราบในมาตรฐานการดึงข้อมูลว่ามีประเภทการตอบกลับอื่น ๆ อีกสองประเภทซึ่งสถานะถูกกำหนดให้เป็น 0 ซึ่งการมีอยู่เกี่ยวข้องกับคำขอข้ามแหล่งที่มาและนโยบายแหล่งกำเนิดเดียวกัน:

การตอบสนองที่กรองแบบทึบแสงคือการตอบสนองที่กรองแล้วซึ่ง ... สถานะคือ0...

การตอบสนองที่กรองการเปลี่ยนเส้นทางทึบแสงคือการตอบสนองที่กรองซึ่งมี ... สถานะคือ0...

(รายละเอียดอื่น ๆ อีกมากมายเกี่ยวกับประเภทการตอบกลับทั้งสองนี้ถูกละไว้)

แต่นอกเหนือจากนี้ยังมีอีกหลายกรณีที่อัลกอริทึมการดึงข้อมูล (แทนที่จะเป็นข้อมูลจำเพาะ XHR ซึ่งเราได้ดูไปแล้ว) เรียกร้องให้เบราว์เซอร์ส่งคืนข้อผิดพลาดของเครือข่าย! แท้จริงแล้ววลี "ส่งกลับข้อผิดพลาดของเครือข่าย" ปรากฏ40 ครั้งในมาตรฐานการดึงข้อมูล ฉันจะไม่พยายามแสดงรายการทั้งหมด 40 รายการที่นี่ แต่ฉันทราบว่าประกอบด้วย:

• กรณีที่ไม่รู้จักรูปแบบของคำขอ (เช่นพยายามส่งคำขอไปที่ madeupscheme: //foobar.com)
• คำสั่งที่คลุมเครืออย่างน่าอัศจรรย์ "หากมีข้อสงสัยโปรดส่งคืนข้อผิดพลาดของเครือข่าย" ในอัลกอริทึมสำหรับจัดการ ftp: // และ file: // URLs
• การเปลี่ยนเส้นทางไม่มีที่สิ้นสุด: "หากจำนวนการเปลี่ยนเส้นทางของคำขอเท่ากับยี่สิบแสดงข้อผิดพลาดของเครือข่าย"
• ปัญหาที่เกี่ยวข้องกับ CORS จำนวนมากเช่น "หากการตอบสนองของ httpRequest ไม่ใช่" cors "และการตรวจสอบนโยบายทรัพยากรข้ามแหล่งที่มาพร้อมกับคำขอและการตอบกลับที่ถูกบล็อกจากนั้นส่งคืนข้อผิดพลาดของเครือข่าย"
• การเชื่อมต่อล้มเหลว: "หากการเชื่อมต่อล้มเหลวให้ส่งคืนข้อผิดพลาดของเครือข่าย"

ในคำอื่น ๆ : เมื่อใดก็ตามที่มีอะไรผิดพลาดอื่น ๆกว่าการรหัสสถานะข้อผิดพลาด HTTP จริงเช่น 500 หรือ 400 จากเซิร์ฟเวอร์คุณจบลงด้วยแอตทริบิวต์สถานะของ 0 บนวัตถุ XHR หรือดึงข้อมูลวัตถุการตอบสนองในเบราว์เซอร์ จำนวนสาเหตุเฉพาะที่เป็นไปได้ที่ระบุไว้ในข้อมูลจำเพาะมีมากมาย

สุดท้าย: หากคุณสนใจประวัติของข้อมูลจำเพาะด้วยเหตุผลบางประการโปรดทราบว่าคำตอบนี้ได้รับการเขียนใหม่ทั้งหมดในปี 2020 และคุณอาจสนใจในการแก้ไขคำตอบนี้ก่อนหน้านี้ซึ่งแยกวิเคราะห์ข้อสรุปเดียวกันออกจากข้อมูลจำเพาะ W3 ที่เก่ากว่า (และง่ายกว่ามาก ) สำหรับ XHR ก่อนหน้านี้จะถูกแทนที่ด้วยข้อกำหนด WhatWG ที่ทันสมัยและซับซ้อนกว่าคำตอบนี้อ้างถึง

สถานะ 0 ปรากฏขึ้นเมื่อมีการยกเลิกการโทรของ ajax ก่อนที่จะได้รับคำตอบโดยการรีเฟรชเพจหรือขอ URL ที่ไม่สามารถเข้าถึง

สถานะนี้ไม่ได้รับการจัดทำเป็นเอกสาร แต่มีอยู่ใน ajax และ makeRequest call จาก gadget.io

จากเอกสารประกอบhttp://www.w3.org/TR/XMLHttpRequest/#the-status-attribute หมายถึงคำขอถูกยกเลิกก่อนที่จะไปที่ใดก็ได้

รู้ว่ามันเป็นโพสต์เก่า แต่ปัญหาเหล่านี้ยังคงมีอยู่

นี่คือข้อค้นพบบางส่วนของฉันเกี่ยวกับเรื่องนี้ซึ่งอธิบายอย่างคร่าวๆ

"สถานะ" 0 หมายถึงหนึ่งใน 3 สิ่งตามข้อกำหนด XMLHttpRequest:

• การแก้ปัญหาชื่อ dns ล้มเหลว (เช่นเมื่อดึงปลั๊กเครือข่ายออก)

• เซิร์ฟเวอร์ไม่ตอบ (aka ไม่สามารถเข้าถึงได้หรือไม่ได้รับการตอบสนอง)

• คำขอถูกยกเลิกเนื่องจากปัญหา CORS (การทำแท้งดำเนินการโดยตัวแทนผู้ใช้และทำตาม OPTIONS ก่อนการบินที่ล้มเหลว)

หากคุณต้องการก้าวไปไกลกว่านั้นให้ดำน้ำลึกลงไปในส่วนลึกของ XMLHttpRequest ฉันขอแนะนำให้อ่านลำดับการอัปเดตสถานะพร้อม ([0,1,2,3,4] คือลำดับปกติ [0,1,4] สอดคล้องกับสถานะ 0, [0,1,2,4] หมายถึงไม่มีเนื้อหา ส่งซึ่งอาจเป็นข้อผิดพลาดหรือไม่) คุณอาจต้องการแนบผู้ฟังเข้ากับ xhr (onreadystatechange, onabort, onerror, ontimeout) เพื่อหารายละเอียด

จากข้อมูลจำเพาะ ( XHR Living spec ):

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;

ตั้งแต่ iOS 9 คุณต้องเพิ่ม "App Transport Security Settings" ลงในไฟล์ info.plist ของคุณและอนุญาต "Allow Arbitrary Loads" ก่อนที่จะร้องขอไปยังบริการเว็บ HTTP ที่ไม่ปลอดภัย ฉันมีปัญหานี้ในแอปหนึ่งของฉัน

ใช่บางวิธีที่การโทร ajax ถูกยกเลิก สาเหตุอาจจะตามมา

1. ก่อนเสร็จสิ้นการร้องขอ ajax ผู้ใช้ไปที่หน้าอื่น
2. คำขอ Ajax หมดเวลา
3. เซิร์ฟเวอร์ไม่สามารถตอบสนองใด ๆ