Mã Trạng thái HTTP bằng 0 có bất kỳ ý nghĩa nào không?

Có vẻ như khi bạn tạo một XMLHttpRequest từ một tập lệnh trong trình duyệt, nếu trình duyệt được đặt để hoạt động ngoại tuyến hoặc nếu cáp mạng được kéo ra, yêu cầu hoàn thành với lỗi và với trạng thái = 0. 0 không được liệt kê trong số được phép Mã trạng thái HTTP.

Mã trạng thái 0 nghĩa là gì? Nó có nghĩa giống nhau trên tất cả các trình duyệt và cho tất cả các tiện ích máy khách HTTP không? Nó là một phần của thông số HTTP hay nó là một phần của một số thông số giao thức khác? Có vẻ như yêu cầu HTTP hoàn toàn không thể được thực hiện, có lẽ vì địa chỉ máy chủ không thể được giải quyết.

Thông báo lỗi nào phù hợp để hiển thị cho người dùng? "Bạn không được kết nối với Internet hoặc trang web đang gặp sự cố hoặc có thể có lỗi đánh máy trong địa chỉ"?

Tôi nên thêm vào điều này rằng tôi thấy hành vi trong FireFox khi được đặt thành "Làm việc ngoại tuyến", nhưng không phải trong Microsoft Internet Explorer khi được đặt thành "Làm việc ngoại tuyến". Trong IE, người dùng nhận được một hộp thoại cung cấp tùy chọn truy cập trực tuyến. FireFox không thông báo cho người dùng trước khi trả lại lỗi.

Tôi hỏi điều này để đáp lại yêu cầu "hiển thị thông báo lỗi tốt hơn". Những gì Internet Explorer làm là tốt. Nó cho người dùng biết điều gì đang gây ra sự cố và cung cấp cho họ tùy chọn để khắc phục nó. Để đưa ra một UX tương đương với FireFox, tôi cần suy ra nguyên nhân của sự cố và thông báo cho người dùng. Vậy tổng thể tôi có thể suy ra điều gì từ Trạng thái 0? Nó có một ý nghĩa phổ quát hay nó không cho tôi biết gì?

Câu trả lời ngắn

Nó không phải là mã phản hồi HTTP, nhưng nó được WhatWG ghi lại như một giá trị hợp lệ cho thuộc tính trạng thái của một XMLHttpRequesthoặc một phản hồi Tìm nạp.

Nói chung, nó là giá trị mặc định được sử dụng khi không có mã trạng thái HTTP thực để báo cáo và / hoặc xảy ra lỗi khi gửi yêu cầu hoặc nhận phản hồi. Các tình huống có thể xảy ra trong trường hợp này bao gồm, nhưng không giới hạn:

• Yêu cầu chưa được gửi hoặc đã bị hủy bỏ.
• Trình duyệt vẫn đang chờ nhận trạng thái phản hồi và tiêu đề.
• Kết nối bị ngắt trong khi yêu cầu.
• Yêu cầu đã hết thời gian chờ.
• Yêu cầu gặp phải vòng lặp chuyển hướng vô hạn.
• Trình duyệt biết trạng thái phản hồi, nhưng bạn không được phép truy cập nó do các hạn chế bảo mật liên quan đến Chính sách nguồn gốc .

Câu trả lời dài

Đầu tiên, cần nhắc lại: 0 không phải là mã trạng thái HTTP. Có một danh sách đầy đủ về chúng trong RFC 7231 Phần 6.1 , không bao gồm 0 và phần giới thiệu của phần 6 nói rõ rằng

Phần tử mã trạng thái là một mã số nguyên có ba chữ số

mà 0 thì không.

Tuy nhiên, 0 dưới dạng giá trị .statusthuộc tính của đối tượng XMLHttpRequest được ghi lại, mặc dù hơi khó để theo dõi tất cả các chi tiết liên quan. Chúng tôi bắt đầu tại https://xhr.spec.whatwg.org/#the-status-attribute , ghi lại .statusthuộc tính, chỉ đơn giản là:

Các statusthuộc tính phải trả lại phản ứng của tình trạng .

Điều đó nghe có vẻ trống rỗng và phiến diện, nhưng thực tế có thông tin ở đây! Hãy nhớ rằng tài liệu này đang nói ở đây về .responsethuộc tính của một XMLHttpRequest, không phải là một phản hồi, vì vậy, điều này cho chúng ta biết rằng định nghĩa trạng thái trên đối tượng XHR được chuyển sang định nghĩa về trạng thái của phản hồi trong thông số Tìm nạp.

Nhưng đối tượng phản hồi nào? Điều gì sẽ xảy ra nếu chúng tôi thực sự chưa nhận được phản hồi? Liên kết nội dòng về từ "phản hồi" đưa chúng ta đến https://xhr.spec.whatwg.org/#response , giải thích:

An XMLHttpRequestcó một phản hồi liên quan. Trừ khi có quy định khác, đó là lỗi mạng .

Vì vậy, phản hồi có trạng thái mà chúng tôi nhận được theo mặc định là lỗi mạng. Và bằng cách tìm kiếm ở mọi nơi cụm từ "đặt phản hồi thành" được sử dụng trong thông số XHR, chúng ta có thể thấy rằng cụm từ "đặt phản hồi thành" được đặt ở năm vị trí:

• Đối với một lỗi mạng, khi:

  • các open()phương pháp được gọi, hoặc
  • của phản ứng cơ thể của dòng được errored (xem các thuật toán được mô tả trong các tài liệu cho các send()phương pháp )
  • các lá cờ timed out được thiết lập, gây ra các bước yêu cầu báo lỗi để chạy
  • các abort()phương pháp được gọi là, gây ra các bước yêu cầu báo lỗi để chạy

• Đối với phản hồi được tạo ra bằng cách gửi yêu cầu bằng Tìm nạp, bằng cách thực hiện nhiệm vụ phản hồi quy trình Tìm nạp (nếu yêu cầu XHR không liên tục) hoặc tác vụ cuối nội dung phản hồi quy trình Tìm nạp (nếu yêu cầu XHR là đồng bộ).

Nhìn vào tiêu chuẩn Tìm nạp , chúng ta có thể thấy rằng:

Một lỗi mạng là một phản ứng có tình trạng luôn luôn là0

vì vậy chúng tôi có thể ngay lập tức cho biết rằng chúng tôi sẽ thấy trạng thái 0 trên đối tượng XHR trong bất kỳ trường hợp nào mà thông số XHR cho biết phản hồi phải được đặt thành lỗi mạng. (Thật thú vị, điều này bao gồm trường hợp luồng của cơ thể bị "lỗi", điều mà thông số Tìm nạp cho chúng ta biết có thể xảy ra trong quá trình phân tích cú pháp cơ thể sau khi nhận được trạng thái - vì vậy về lý thuyết, tôi cho rằng đối tượng XHR có thể có trạng thái của nó đặt thành 200, sau đó gặp lỗi hết bộ nhớ hoặc lỗi gì đó trong khi nhận nội dung và do đó, thay đổi trạng thái của nó trở lại 0)

Chúng tôi cũng lưu ý trong tiêu chuẩn Tìm nạp rằng tồn tại một số loại phản hồi khác có trạng thái được xác định là 0, sự tồn tại của chúng liên quan đến các yêu cầu có nguồn gốc chéo và chính sách cùng nguồn gốc:

Phản hồi được lọc không rõ ràng là phản hồi đã lọc có ... trạng thái là 0...

Phản hồi được lọc chuyển hướng không rõ ràng là phản hồi được lọc có ... trạng thái là 0...

(bỏ qua nhiều chi tiết khác về hai loại phản hồi này).

Nhưng ngoài những điều này, cũng có nhiều trường hợp thuật toán Tìm nạp (chứ không phải thông số XHR mà chúng ta đã xem xét) yêu cầu trình duyệt trả về lỗi mạng! Thật vậy, cụm từ "trả lại lỗi mạng" xuất hiện 40 lần trong tiêu chuẩn Tìm nạp. Tôi sẽ không cố gắng liệt kê tất cả 40 ở đây, nhưng tôi lưu ý rằng chúng bao gồm:

• Trường hợp không nhận dạng được lược đồ của yêu cầu (ví dụ: cố gắng gửi yêu cầu đến madeupscheme: //foobar.com)
• Hướng dẫn mơ hồ tuyệt vời "Khi nghi ngờ, hãy trả lại lỗi mạng." trong các thuật toán để xử lý ftp: // và tệp: // URL
• Chuyển hướng vô hạn: "Nếu số chuyển hướng của yêu cầu là 20, hãy trả về lỗi mạng."
• Một loạt các vấn đề liên quan đến CORS, chẳng hạn như "Nếu phản hồi của httpRequest bị nhiễm bẩn không phải là" cors "và kiểm tra chính sách tài nguyên chéo có bị chặn trả về yêu cầu và phản hồi, thì trả về lỗi mạng."
• Lỗi kết nối: "Nếu kết nối không thành công, hãy trả về lỗi mạng."

Nói cách khác: bất cứ khi nào họ gặp khó khăn khác hơn nhận được một HTTP thực mã trạng thái lỗi như 500 hoặc 400 từ máy chủ, bạn kết thúc với một thuộc tính trạng thái 0 trên đối tượng XHR hoặc Fetch đối tượng phản ứng trong trình duyệt. Số lượng các nguyên nhân cụ thể có thể được liệt kê trong thông số kỹ thuật là rất lớn.

Cuối cùng: nếu bạn quan tâm đến lịch sử của thông số kỹ thuật vì lý do nào đó, hãy lưu ý rằng câu trả lời này đã được viết lại hoàn toàn vào năm 2020 và bạn có thể quan tâm đến bản sửa đổi trước của câu trả lời này , về cơ bản phân tích các kết luận giống nhau từ Thông số kỹ thuật W3 cũ hơn (và đơn giản hơn nhiều ) cho XHR, trước khi chúng được thay thế bằng thông số kỹ thuật WhatWG hiện đại hơn và phức tạp hơn mà câu trả lời này đề cập đến.

trạng thái 0 xuất hiện khi một lệnh gọi ajax bị hủy trước khi nhận được phản hồi bằng cách làm mới trang hoặc yêu cầu một URL không thể truy cập được.

trạng thái này không được ghi lại nhưng tồn tại qua lệnh gọi ajax và makeRequest từ gadget.io.

từ tài liệu http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute có nghĩa là một yêu cầu đã bị hủy trước khi đi đến bất kỳ đâu

Biết đó là một bài cũ. Nhưng những vấn đề này vẫn tồn tại.

Đây là một số phát hiện của tôi về chủ đề này, được giải thích rõ ràng.

"Trạng thái" 0 có nghĩa là một trong 3 điều, theo thông số XMLHttpRequest:

• Không phân giải được tên dns (ví dụ: khi phích cắm mạng được rút ra)

• máy chủ không trả lời (còn gọi là không thể truy cập hoặc không trả lời)

• yêu cầu đã bị hủy bỏ do sự cố CORS (tác nhân người dùng thực hiện phá thai và sau chuyến bay trước OPTIONS không thành công).

Nếu bạn muốn đi xa hơn, hãy đi sâu vào nội dung của XMLHttpRequest. Tôi khuyên bạn nên đọc trình tự cập nhật trạng thái sẵn sàng ([0,1,2,3,4] là trình tự bình thường, [0,1,4] tương ứng với trạng thái 0, [0,1,2,4] có nghĩa là không có nội dung gửi mà có thể là một lỗi hoặc không). Bạn cũng có thể muốn gắn người nghe vào xhr (onreadystatechange, onabort, onerror, ontimeout) để tìm hiểu chi tiết.

Từ thông số kỹ thuật ( 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;

Kể từ iOS 9, bạn cần thêm "Cài đặt bảo mật truyền tải ứng dụng" vào tệp info.plist của mình và cho phép "Cho phép tải tùy ý" trước khi đưa ra yêu cầu đối với dịch vụ web HTTP không an toàn. Tôi gặp sự cố này trong một trong các ứng dụng của mình.

Có, một số cách gọi ajax bị hủy bỏ. Nguyên nhân có thể sau đây.

1. Trước khi hoàn thành yêu cầu ajax, người dùng đã điều hướng đến trang khác.
2. Yêu cầu Ajax có thời gian chờ.
3. Máy chủ không thể trả lại bất kỳ phản hồi nào.