HTTP 상태 코드 0은 의미가 있습니까?

브라우저의 스크립트에서 XMLHttpRequest를 만들 때 브라우저가 오프라인으로 작동하도록 설정되어 있거나 네트워크 케이블이 분리되면 요청이 오류와 함께 완료되고 상태 = 0으로 표시됩니다. 0은 허용 항목에 나열되지 않습니다. HTTP 상태 코드.

상태 코드 0은 무엇을 의미합니까? 모든 브라우저와 모든 HTTP 클라이언트 유틸리티에서 동일한 의미입니까? HTTP 사양의 일부입니까 아니면 다른 프로토콜 사양의 일부입니까? 서버 주소를 확인할 수 없기 때문에 HTTP 요청을 전혀 할 수 없음을 의미하는 것 같습니다.

사용자에게 표시하는 데 적합한 오류 메시지는 무엇입니까? "인터넷에 연결되어 있지 않거나 웹 사이트에 문제가 있거나 주소에 입력 오류가있을 수 있습니다."

"오프라인으로 작업"으로 설정하면 FireFox에서 동작을 볼 수 있지만 "오프라인으로 작업"으로 설정하면 Microsoft Internet Explorer에서 볼 수 없다는 점을 추가해야합니다. IE에서 사용자는 온라인으로 전환 할 수있는 옵션을 제공하는 대화 상자를 얻습니다. FireFox는 오류를 반환하기 전에 사용자에게 알리지 않습니다.

"더 나은 오류 메시지 표시"요청에 대한 응답으로 요청합니다. Internet Explorer의 기능은 좋습니다. 사용자에게 문제의 원인을 알려주고 문제를 해결할 수있는 옵션을 제공합니다. FireFox와 동등한 UX를 제공하려면 문제의 원인을 유추하고 사용자에게 알려야합니다. 그렇다면 상태 0에서 총 무엇을 추론 할 수 있습니까? 보편적 인 의미를 가지고 있습니까, 아니면 아무 말도하지 않습니까?

짧은 답변

HTTP 응답 코드는 아니지만 WhatWG에서 XMLHttpRequest또는 Fetch 응답 의 상태 속성에 대한 유효한 값으로 문서화합니다 .

일반적으로 보고 할 실제 HTTP 상태 코드가 없거나 요청을 보내거나 응답을받는 동안 오류가 발생한 경우 사용되는 기본값 입니다. 이 경우 가능한 시나리오에는 다음이 포함되지만 이에 국한되지는 않습니다.

• 요청이 아직 전송되지 않았거나 중단되었습니다.
• 브라우저는 여전히 응답 상태 및 헤더를 수신하기를 기다리고 있습니다.
• 요청 중에 연결이 끊어졌습니다.
• 요청 시간이 초과되었습니다.
• 요청에 무한 리디렉션 루프가 발생했습니다.
• 브라우저는 응답 상태를 알고 있지만 동일 출처 정책 과 관련된 보안 제한으로 인해 액세스 할 수 없습니다 .

긴 답변

먼저, 0은 HTTP 상태 코드가 아닙니다. RFC 7231 섹션 6.1 에는 0을 포함하지 않는 전체 목록이 있으며 섹션 6의 소개에서는 다음과 같이 명확하게 설명합니다.

상태 코드 요소는 3 자리 정수 코드입니다.

0은 아닙니다.

그러나 .status모든 관련 세부 정보를 추적하는 것은 약간 까다 롭지 만 XMLHttpRequest 객체 의 속성 값으로 0 이 문서화되어 있습니다. https://xhr.spec.whatwg.org/#the-status-attribute 에서 시작 하여 .status속성을 문서화합니다 .

status속성은 반환해야 응답 의 상태를 .

공허하고 팽팽하게 들릴지 모르지만 실제로 여기에 정보가 있습니다! 이 문서는 여기서 응답이 아닌 의 .response속성에 대해 이야기 XMLHttpRequest하고 있으므로 XHR 객체의 상태 정의가 Fetch 사양의 응답 상태 정의로 연기된다는 것을 알려줍니다.

그러나 어떤 응답 대상? 실제로 아직 응답을받지 못했다면 어떻게해야합니까? "응답"이라는 단어의 인라인 링크를 클릭하면 https://xhr.spec.whatwg.org/#response 로 이동합니다.

에 XMLHttpRequest연관된 응답이 있습니다. 달리 명시되지 않는 한 네트워크 오류 입니다.

따라서 우리가받는 상태의 응답은 기본적으로 네트워크 오류입니다. XHR 사양에서 "set response to" 라는 문구 가 사용되는 모든 곳을 검색 하면 다음과 같이 5 곳에 설정되어 있음을 알 수 있습니다.

• 네트워크 오류에 대해 다음과 같은 경우 :

  • open()방법 전화, 또는
  • 응답의 본체 의 스트림이 된다 에 오류 용 문서에 기술 된 알고리즘을 참조 ( 방법send() )
  • 초과 플래그 일으키는 설정 요청 오류 단계 실행에를
  • abort()방법은 원인이라고 요청 오류 단계를 실행

• Fetch를 사용하여 요청을 전송하여 생성 된 응답에 대해 Fetch 프로세스 응답 작업 ( XHR 요청이 비동기 인 경우 ) 또는 Fetch 프로세스 응답 본문 끝 작업 (XHR 요청이 동기 인 경우)을 통해 생성됩니다.

Fetch 표준을 살펴보면 다음을 확인할 수 있습니다.

네트워크 오류가 A는 응답 그의 상태를 항상0

따라서 XHR 사양에서 응답을 네트워크 오류로 설정해야한다고 말하는 경우 XHR 개체에서 0 상태를 볼 수 있음을 즉시 알 수 있습니다. (흥미롭게도 여기에는 본문의 스트림이 "오류"되는 경우가 포함됩니다. Fetch 사양은 다음과 같이 본문 을 구문 분석하는 동안 발생할 수 있다고 알려줍니다. 상태를 수신 따라서 이론적으로 XHR 객체가 상태를 가질 수 있다고 가정합니다. 200으로 설정 한 다음 본문을받는 동안 메모리 부족 오류 또는 무언가가 발생하여 상태를 다시 0으로 변경합니다.)

또한 Fetch 표준에서 상태가 0으로 정의 된 몇 가지 다른 응답 유형이 있으며, 그 존재는 교차 출처 요청 및 동일 출처 정책과 관련됩니다.

불투명 필터링 된 응답은 ... 상태가 다음 과 같은 필터링 된 응답 입니다.0 ... .

불투명 리디렉션 필터링 된 응답은 ... 상태가 ... 인 필터링 된 응답 입니다 0.

(이 두 가지 응답 유형에 대한 기타 여러 세부 사항은 생략 됨).

그러나이 외에도 Fetch 알고리즘 (이미 살펴본 XHR 사양이 아니라)이 브라우저에서 네트워크 오류를 반환하도록 요청하는 경우도 많습니다 ! 실제로 Fetch 표준에서는 "네트워크 오류 반환"이라는 문구가 40 번 나타납니다 . 여기에 40 개를 모두 나열하지는 않겠지 만 다음과 같은 내용이 포함되어 있습니다.

• 요청의 체계가 인식되지 않는 경우 (예 : madeupscheme : //foobar.com에 요청을 보내려는 경우)
• 놀랍도록 모호한 명령 "의심스러운 경우 네트워크 오류를 반환하십시오." ftp : // 및 file : // URL을 처리하기위한 알고리즘
• 무한 리디렉션 : "요청의 리디렉션 수가 20 인 경우 네트워크 오류를 반환합니다."
• "httpRequest의 응답 오염이"cors "가 아니고 요청 및 응답이 차단 된 출처 간 리소스 정책 검사가 차단 된 경우 네트워크 오류를 반환합니다."와 같은 CORS 관련 문제가 많습니다.
• 연결 실패 : " 연결 이 실패하면 네트워크 오류를 반환합니다."

즉, 무언가 잘못 될 때마다 다른 , 서버에서 500 또는 400과 같은 실제 HTTP 오류 상태 코드를받는 XHR 개체의 상태 속성이 0이거나 브라우저의 응답 개체를 가져옵니다. 사양에 열거 된 가능한 특정 원인의 수는 방대합니다.

마지막으로, 어떤 이유로 사양의 역사에 관심이 있다면이 답변은 2020 년에 완전히 재 작성되었으며이 답변의 이전 개정판에 관심이있을 수 있습니다 . 이 답변이 참조하는 더 현대적이고 복잡한 WhatWG 사양으로 대체되기 전에 XHR에 대한 이전 (그리고 훨씬 더 간단한) W3 사양.

상태 0은 페이지를 새로 고치거나 연결할 수없는 URL을 요청하여 응답을 받기 전에 ajax 호출이 취소 된 경우 나타납니다.

이 상태는 문서화되어 있지 않지만 gadget.io의 ajax 및 makeRequest 호출을 통해 존재합니다.

http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute 문서 는 어디로 든 가기 전에 요청이 취소되었음을 의미합니다.

오래된 게시물이라는 것을 알아 두십시오. 그러나 이러한 문제는 여전히 존재합니다.

다음은 주제에 대한 제가 찾은 결과입니다.

"상태"0은 XMLHttpRequest 사양에 따라 다음 세 가지 중 하나를 의미합니다.

• DNS 이름 확인 실패 (예 : 네트워크 플러그를 뽑은 경우)

• 서버가 응답하지 않음 (일명 도달 할 수 없거나 응답하지 않음)

• CORS 문제로 인해 요청이 중단되었습니다 (사용자 에이전트가 중단을 수행하고 실패한 OPTIONS 프리 플라이트를 따릅니다).

더 나아가고 싶다면 XMLHttpRequest의 내부에 대해 자세히 알아보십시오. 준비 상태 업데이트 시퀀스 ([0,1,2,3,4]는 정상 시퀀스, [0,1,4]는 상태 0에 해당, [0,1,2,4]는 내용이 없음을 의미 함) 읽기를 제안합니다. 오류 일 수도 있고 아닐 수도 있습니다.) 세부 사항을 파악하기 위해 리스너를 xhr (onreadystatechange, onabort, onerror, ontimeout)에 연결할 수도 있습니다.

사양에서 ( 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;

iOS 9부터는 "앱 전송 보안 설정"을 info.plist 파일에 추가하고 비보안 HTTP 웹 서비스에 요청하기 전에 "임의로드 허용"을 허용해야합니다. 내 앱 중 하나에서이 문제가 발생했습니다.

예, 아약스 호출이 어떻게 중단되었는지 일부. 원인은 다음과 같을 수 있습니다.

1. ajax 요청이 완료되기 전에 사용자가 다른 페이지로 이동했습니다.
2. Ajax 요청에 시간 초과가 있습니다.
3. 서버가 응답을 반환 할 수 없습니다.