[WEB] HTTP 상태코드를 알아보자

클라이언트와 서버가 요청과 응답을 주고 받을 때 서버는 응답의 결과가 어떨지 알려줘야 합니다.

결과의 내용을 response body에 상세하게 적어줄 수도 있지만 다양하게 발생하는 에러에 이를 다 적는 것은 적지 않은 시간이 소요될 뿐 아니라 다양한 서버 개발자가 함께 작업하다보면 메세지의 포멧이 다양해져 클라이언트와의 소통에 문제가 생길 수 있습니다.

그렇기 때문에 세자리 숫자로 결과가 어떨지에 대한 표준 약속을 정하고 이를 HTTP 상태코드 라고 합니다.

상태코드의 첫번째 자리는 1~5가 위치하며 이를 통해 크게 범주를 나눌 수 있습니다.

• 1 : 정보응답

  • 요청을 받았으며 프로세스를 계속 진행합니다.

• 2 : 성공

  • 요청을 성공적으로 받았습니다.

• 3 : 리다이렉션

  • 요청을 완료하기 위해 추가 작업이 필요합니다.

• 4 : 클라이언트 오류

  • 요청의 문법이 잘못되었거나 요청을 처리할 수 없습니다.

• 5 : 서버 오류

  • 서버가 명백히 유효한 요청에 대해 충족을 실패했습니다.

각각에 대해서 좀 더 자세히 알아보겠습니다.

 

1: 정보 응답

100 Continue

임시적인 응답으로 현재까지 문제없고 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 됨을 뜻합니다.

 

101 Switching Protocol

클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 사용되며 서버에서 프로토콜을 변경할 것을 뜻합니다.

간단한 예시를 통해 알아봅시다.

클라이언트가 아래와 같이 WebSocket 프로토콜로 전환하는 요청을 하였습니다.

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

 

서버와 해당 프로토콜을 지원하는 경우, 위 예시에서는 WebSocket 프로토콜을 지원하는 경우 서버는 클라이언트에게 바꾸겠다는 사실을 알리고 프로토콜을 전환해야합니다.

이 때 사용하는 것이 101 Switching Protocol 입니다.

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

 

102 Processing

서버가 요청을 수신하여 처리하고 있지만 아직 응답을 할 수 없는 상황을 뜻합니다.

 

103 Early Hints

이 상태 코드는 주로 Link 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트가 사전 로딩을 시작할 수 있도록 합니다.

Link 헤더는 다음과 같이 사용하여 문서를 랜더링하기 위해 특정 CSS나 script 파일이 필요하다고 알릴 수 있습니다.

HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </main.css>; rel=preload; as=style
Link: </newstyle.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script

 

그리고 103 Early Hints 을 사용하면 원래의 응답을 보내기 전에 미리 클라이언트에게 이를 알릴 수 있습니다.

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script

HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script

 

 

2: 성공 응답

200 OK

요청이 성공적으로 되었다는 의미입니다. 성공의 의미는 HTTP 메서드에 따라 다릅니다.

• GET : 리소스를 불러와서 메세지 바디에 전송되었습니다.
• HEAD : 개체 해더가 메세지 바디에 있습니다.
• PUT | POST : 수행 결과에 대한 리소스가 메세지 바디에 전송되었습니다.
• TRACE : 메세지 바디는 서버에서 수신한 요청 메세지를 포함하고 있습니다.

일반적으로 캐시 가능합니다.

 

201 Created

요청이 성공적이었으며 그 결과로 새로운 리소스를 생성하였습니다.

일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라옵니다.

일반적으로는 POST를 통해 새로운 리소스를 만들지만 PUT 요청을 통해서도 가능합니다.

둘의 결정적인 차이는 POST는 식별자를 보내지 않고 PUT은 식별자를 보냅니다.

POST /board
PUT /board/17

그리고 명등성에서 차이가 있는데 POST는 여러 번 요청 시, 요청의 횟수만큼 리소스를 생성하고 PUT은 같은 리소스를 수정하기만 합니다.

 

202 Accepted

요청을 수신하였지만 그에 응하여 행동할 수 없습니다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않습니다. 이것은 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들어졌습니다.

 

203 Non-Authoritative Information

클라이언트와 서버 사이에 프록시에서 사용할 수 있는 상태코드입니다.

프록시가 형식을 변환하거나 HTML 본문에 무언가를 추가할 경우, 프록시는 상태코드를 203 Non-Authoritative Information 로 변경하여 클라이언트에게 변경되었음을 알립니다.

하지만 이 경우, 기존의 상태 코드를 확인할 수 없는 문제가 발생하기 때문에 RFC에서는 Warning 헤더 사용할 것을 권유합니다.

• 203 Non-Authoritative Information

  HTTP/1.1 203 Non-Authoritative Information
  Content-Type: text/plain
  Content-Length: 515
  

• Waring 헤더

  HTTP/1.1 200 OK
  Content-Type: text/plain
  Warning: 214 proxy.example.org "We censored the response. srry"
  Content-Length: 515
  

일반적으로 캐시 가능합니다.

 

204 No Content

요청이 성공적이었으며 이를 수행했지만 응답 본문에 보낼 컨텐츠가 없습니다.

하지만 헤더는 의미있을 수 있습니다. 사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있습니다.

일반적으로 캐시 가능합니다.

 

205 Reset Content

요청을 완수한 이후에 사용자 에이전트에게 이 요청을 보낸 문서 뷰를 리셋하라고 알려줍니다.

예를 들어 사용자가 특정 Form을 작성하여 이를 서버에 제출할 경우, 해당 페이지를 새로고침하지 않고 해당 Form만 초기화 해야하는 경우가 있습니다.

이 때 Form의 정보들이 유효한 경우, 205 Reset Content 를 응답하여 사용자가 새로고침은 하지 않고 Form만 초기화 할 수 있도록 합니다.

 

206 Partial Content

클라이언트에서 복수의 스트림을 분할 다운로드를 하고자 범위 헤더를 전송했기 때문에 사용됩니다.

클라이언트가 범위 요청을 발행하고 서버가 이를 처리할 수 있는 경우, 206 Partial Content 와 Content-Range 헤더와 함께 특정 범위만 다시 전송하고 있음을 클라이언트에게 전달할 수 있습니다.

클라이언트가 video.mp4에 대해 bytes의 범위를 요구하면,

GET /video.mp4 HTTP/1.1
Range: bytes=1048576-2097152

 

서버는 이에 대해 특정 범위에 대해서 응답합니다.

HTTP/1.1 206 Partial Content
Content-Range: bytes 1048576-2097152/3145728
Content-Type: video/mp4

 

207 Multi-Status (WebDAV)

여러 리소스가 여러 상태 코드인 상황이 적절한 경우에 해당되는 정보를 전달합니다.

 

208 Multi-Status (WebDAV)

DAV에서 사용됩니다: propstat(property와 status의 합성어) 응답 속성으로 동일 컬렉션으로 바인드된 복수의 내부 멤버를 반복적으로 열거하는 것을 피하기 위해 사용됩니다.

 

226 IM Used (HTTP Delta encoding)

서버가 GET 요청에 대한 리소스의 의무를 다 했고, 그리고 응답이 하나 또는 그 이상의 인스턴스 조작이 현재 인스턴스에 적용이 되었음을 알려줍니다. 여기서 IM은 Instance Manipulation을 의미합니다.

브라우저와 같은 클라이언트는 특정 리소스들에 대해서 캐시하게 됩니다.

이 때 리소스가 서버 측에서 변경되면 서버는 전체 리소스를 클라이언트에게 보내줘야하는데 약간의 리소스 변경에 대해 전체를 다시 보내는 것은 낭비입니다.

226 IM Used를 사용하면 서버가 변경 사항만 다시 보낼 수 있습니다.

 

 

3. 리다이렉션

300 Multiple Choice

요청에 대해서 하나 이상의 응답이 가능합니다. 사용자 에이전트 또는 사용자는 그중에 하나를 반드시 선택해야 합니다. 응답 중 하나를 선택하는 방법에 대한 표준화 된 방법은 존재하지 않습니다.

 

301 Moved Permanently

요청한 리소스의 URI가 변경되었음을 의미합니다. 새로운 URI가 Location응답 헤더에 주어집니다.

브라우저는 이 페이지로 리다이렉트하고 검색엔진은 해당 리소스로 연결되는 링크를 갱신합니다.

 

302 Found

요청한 리소스의 URI가 일시적으로 변경되었음을 의미합니다.

301이 Moved Permanently 였다면 302는 Moved Temporarily 입니다.

이는 검색엔진이 원래의 URI로 인지하게 하고 컨텐츠만 새로운 URI로 바꾸는데 사용됩니다.

 

301 Moved Permanently VS 302 Found

둘은 겉보기에 비슷해보이지만 검색엔진의 관점에서 가장 큰 차이가 있습니다.

예를 들어 인기제품이 일시적으로 재고가 떨어져서 해당 제품의 페이지를 일시적으로 품절 페이지로 이동시키기 위해서는 둘 중 어떤 방식을 택해야 할까요?

만일 301을 사용한다면 품절 페이지의 랭크가 올라갈 것이고 이는 쇼핑몰을 운영하는 입장에서 원하는 바가 아닙니다. 따라서 302를 통해 페이지는 리다이렉션하고 검색엔진은 인기제품의 랭크를 올릴 수 있도록 합니다.

 

303 See Other

클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 함을 의미합니다.

 

304 Not Modified

이것은 캐시를 목적으로 사용됩니다. 이것은 클라이언트에게 응답이 수정되지 않았음을 알려주며, 그러므로 클라이언트는 계속해서 응답의 캐시된 버전을 사용할 수 있습니다.

 

305 Use Proxy

서버는 클라이언트에게 요청한 응답은 반드시 프록시를 통해서 접속해야 함을 의미합니다.

현재는 보안 상의 문제로 사용하지 않습니다.

 

306 Switch Proxy

클라이언트가 이미 프록시를 사용한 경우 새 프록시를 통해서 접속해야 함을 의미합니다.

305와 마찬가지로 현재는 사용하지 않습니다.

 

307 Temporary Redirect

클라리언트가 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메소드를 사용하여 요청해야함을 의미합니다.

302 Found HTTP 응답 코드와 동일하지만 307 Temporary Redirect는 사용자가 반드시 사용된 HTTP 메소드를 변경하지 말아야 합니다.

만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 합니다.

 

308 Permanent Redirect

클라리언트가 요청한 리소스가 영구히 다른 URI에 있으며, 이전 요청과 동일한 메소드를 사용하여 요청해야함을 의미합니다.

301 Moved Permanently HTTP 응답 코드와 동일하지만 308 Permanent Redirect는 사용자가 반드시 HTTP 메소드를 변경하지 말아야 합니다.

만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 합니다.

 

 

4. 클라이언트 오류

400 Bad Request

클라이언트 오류의 일반 오류코드로서 더 적합한 특정 코드가 없을 경우 사용하기에 적합합니다.

 

401 Unauthorized

401 Unauthorized 은 Unauthorized, 미승인이라는 이름으로 사용하고 있지만 의미상 unauthenticated, 비인증이 더 적합합니다.

클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 합니다.

 

402 Payment Required

디지털 결제 시스템에 사용하기 위하여 만들어졌지만 지금 사용되고 있지는 않습니다.

 

403 Forbidden

콘텐츠에 접근할 권한를 가지고 있지 않다는 의미입니다.

401 Unauthorized VS 403 Forbidden

401 Unauthorized 은 서버가 클라이언트가 누군지 모르는 경우로 로그인 등의 인증 작업이 필요합니다.

403 Forbidden은 클라이언트가 누군지는 알지만 해당 클라이언트가 권한이 없을 경우에 필요합니다. 로그인은 하였지만 일반 사용자가 관리자의 권한이 필요한 콘텐츠에 접근할 때 적절합니다.

 

404 Not Found

서버는 요청받은 리소스를 찾을 수 없습니다.

브라우저에서는 알려지지 않은 URL을 의미합니다.

이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있습니다.

서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있습니다.

 

405 Method Not Allowed

요청한 메소드가 지원되지 않음을 의미합니다.

예를 들어 서버에서는 특정 URI에 대해서 GET 요청만을 지원하는데 클라이언트는 POST로 요청을 보낼 경우에 적합니다.

필수적인 메소드인 GET과 HEAD는 이 에러 코드를 리턴할 수 없습니다.

 

406 Not Acceptable

클라이언트가 서버가 지원하지 않는 리소스의 특정 표현을 요청할 때 서버가 이를 받아들이지 않음을 의미합니다.

HTTP에는 콘텐츠 협상이라는 개념이 존재합니다. 이는 클라이언트가 특정 버전의 리소스를 원할 때 서버와 협상을 하는 것입니다.

예를 들어 클라이언트가 application/json 으로 응답을 받고 싶을 때 다음과 같이 Accept Header를 이용하여 요청할 수 있습니다.

GET /foo HTTP/1.1
Accept: application/json

 

서버가 application/json 을 지원하지 않는 경우 406 Not Acceptable 을 응답합니다.

HTTP/1.1 406 Not Acceptable
Server: curveball/0.4
Content-Type: text/html

 

407 Proxy Authentication Required

401 Unauthorized 과 굉장히 유사하지만 인증을 받지 못한 곳이 Proxy입니다.

 

408 Request Timeout

클라이언트가 요청을 너무 느리게 보내 서버가 이를 종료시키고자 하는 의미입니다.

클라이언트는 인터넷 연결 불량 등 다양한 이유로 요청을 느리게 보낼 경우가 생기고 서버는 웹서핑 속도를 올리기 위해 오래된 요청에 대해 연결을 끊습니다.

 

409 Conflict

요청 자체는 유효하지만 서버의 현재 상태와 충돌이 있을 경우를 의미합니다.

충돌은 다양한 경우가 존재하겠지만 예를 들어 폴더에 파일을 추가하고자 할 경우, 폴더가 존재하지 않을 때 해당 코드가 적합합니다.

서버는 응답 본문에 클라이언트가 충돌을 해결하기 위해 어떤 조치를 취해야 하는지 포함할 것이 권장됩니다.

 

410 Gone

클라이언트가 요청한 리소스가 삭제되었고 다시 생기지 않을 경우에 적합합니다.

404 Not Found 도 리소스가 삭제되어 없는 경우지만 410 Gone 은 좀 더 구체적으로 리소스가 의도적으로 삭제된 경우입니다.

 

411 Length Required

서버에서 필요로 하는 Content-Length 헤더 필드가 정의되지 않은 요청이 들어왔기 때문에 서버가 요청을 거절합니다.

 

412 Precondition Failed

클라이언트는 헤더에 있는 전제조건을 사용해 조건부 요청을 할 수 있으며 이 조건이 서버의 전제조건에 적절하지 않음을 의미합니다.

 

413 Payload Too Large

클라이언트의 요청 본문이 너무 커서 서버가 받아들일 수 없을 의미합니다.

클라이언트가 대용량 파일을 업로드할려고 시도할 때 서버가 이를 거부합니다.

만일 오류의 원인이 서버에서 미리 정한 임의의 크기를 넘어서가 아니라 서버에 디스크 공간이 부족한 것이라면 413 Payload Too Large 보다는 507 Insufficient Storage 가 적합합니다.

 

414 URI Too Long

클라이언트가 요청한 URI는 서버에서 처리하지 않기로 한 길이보다 긴 것을 의미합니다.

HTTP 요청의 URI 또는 경로에는 허용되는 기간에 대한 엄격한 제한이 없지만 브라우저와 검색 엔진에는 제한이 있기 때문에 서버에서는 길이 제한을 하는 것이 좋습니다.

 

415 Unsupported Media Type

요청한 미디어 포맷은 서버에서 지원하지 않아 요청을 거부합니다.

POST /new-article HTTP/1.1
Content-Type: text/html

HTTP/1.1 415 Unsupported Media Type
Content-Type: application/json

{"error": "This endpoint only supports text/markdown for new articles"}

 

416 Requested Range Not Satisfiable

Range 헤더 필드에 요청한 지정 범위를 만족시킬 수 없음을 의미합니다.

클라이언트는 서버에게 Range 헤더 필드를 통해서 부분 응답을 요청할 수 있습니다.

예를 들어 동영상의 일부 구간이나 로그의 일부만을 원하는 경우가 있겠죠.

이 때 서버와 범위 요청을 지원하지 않으면 200 OK와 함께 전체 리소스를 반환하고, 범위 요청을 지원한다면 206 Partial Content와 함께 범위에 대한 응답을 합니다.

하지만 클라이언트의 범위가 잘못되었다면 416 Requested Range Not Satisfiable을 사용합니다.

 

417 Expectation Failed

이 응답 코드는 Expect 요청 헤더 필드로 요청한 예상이 서버에서는 적당하지 않음을 의미합니다.

클라이언트가 어떤 동작을 취하기 전에 100 Continue 를 기대하고 요청을 보낼 수 있습니다.

POST /foo/bar HTTP/1.1
Content-Type: application/gzip
Content-Length: 12345678765
Expect: 100-continue

하지만 서버가 이 기능을 지원하지 않는다면 417 Expectation Failed가 적합합니다.

HTTP/1.1 417 Expectation Failed
Content-Type: text/plain

We don't support 100-continue

 

418 I'm a teapot

서버는 커피를 찻 주전자에 끓이는 것을 거절한다는 뜻입니다.

너무 뜬금없지만 IETF는 매년 하나 이상의 만우절 RFC 문서를 게시하고 418 I'm a teapot 는 그 중 하나입니다.

 

421 Misdirected Request

클라이언트에게 잘못된 서버에 연결되었음을 의미합니다.

http/1.1 이후 클라이언트는 Host 헤더를 포함해야 합니다.

GET /contact.html HTTP/1.1
Host: foo.example.org

서버의 도메인이 Host 헤더와 다르다면 클라이언트에게 잘못된 서버와 연결되어 있음을 알립니다.

HTTP/1.1 421 Misdirected Request
Content-Type: text/html

<h1>Switchboard operator error</h1>

 

422 Unprocessable Entity(WebDAV)

요청은 잘 만들어졌지만, 문법 오류로 인하여 따를 수 없는 경우에 적절합니다.

다음과 같은 클라이언트 요청이 들어왔을 경우를 고려해봅시다.

POST /new-article HTTP/1.1
Content-Type: application/json

{ "title": "Hello world!"}

application/json 을 지원하지 않는다면 415 Unsupported Media Type가 적합하고, JSON 자체가 깨진 경우에는 400 Bad Request가 적합합니다.

하지만 위 조건은 모두 충족하지만 json-schema에 의해서 유효성 검사를 통과하지 못한 경우에는 422 Unprocessable Entity가 적절합니다.

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{
  "type" : "https://example/errors/missing-property",
  "status": 422,
  "title": "Missing property: body"
}

 

423 Locked(WebDAV)

리소스는 접근하는 것이 잠겨있습니다.

클라이언트는 http LOCK 메서드 를 실행하여 리소스를 잠그고 나중에 UNLOCK 메서드를 사용하여 리소스를 잠금 해제 할 수 있습니다 .

LOCK이 걸린 리소스에 대해 수정을 하고자하면 오류가 발생하고 423 Locked가 적합합니다.

 

424 Failed Depeedency(WebDAV)

WebDAV는 PROPPATCH 메소드를 사용하여 단일 요청으로 많은 항목을 업데이트 할 수 있습니다.

이 때 항목들의 업데이트는 원자성을 가져야해서 하나라도 실패한다면 전부 실패로 돌아가고 그 때의 응답으로 424 Failed Depeedency 을 사용합니다.

 

426 Upgrade Required

지금의 프로토콜은 불가능하지만 프로토콜을 업그레이드를 하라는 의미입니다.

서버는 Upgrade 헤더와 필요로 하는 프로토콜을 알려주기 위해 426 Upgrade Required에 보냅니다.

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3
Connection: Upgrade

To use this service, you must use HTTP version 3. 

 

428 Precondition Required

여러 클라이언트가 같은 자원을 작성하고 서로의 변경 내용을 덮어쓰는 것을 방지하기 위해, 혹은 클라이언트와 서드파티간의 충돌을 막기 위해 서버에서 전제조건을 필요로 한다는 의미입니다.

다음과 같은 전제조건들이 있습니다.

If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since

 

429 Too Many Requests

클라이언트가 제한된 요청의 양을 넘을 경우, 클라이언트에게 이 사실을 알립니다.

 

431 Request Header Fields Too Large

요청한 헤더 필드가 너무 크기 때문에 서버는 요청을 처리하지 않을 것을 의미합니다.

요청은 크기를 줄인 다음에 다시 전송해야하며 보통 쿠키에 원인이 있습니다.

 

451 Unavailable For Legal Reasons

서버가 법적인 이유로 컨텐츠 제공을 거부하는 것을 의미합니다.

 

 

5. 서버 오류

500 Internal Server Error

일반적인 서버 오류이며 더 적합한 오류가 없는 경우 선택하기에 적합한 오류입니다.

 

501 Not Implemented

서버가 특정 HTTP 메서드를 지원하는 않는 것을 의미합니다.

405 Method Not Allowed 과 유사하지만 결정적인 차이는 405는 클라이언트 오류로 없어야하는 메서드를 호출한 것이지만 501 Not Implemented 은 있어야하는 메서드를 서버가 구현하지 않았음을 의미합니다.

 

502 Bad Gateway

서버와 클라이언트 사이에 프록시가 존재하고 프록시는 정상적으로 동작하고 있으나 원래의 서버에 문제가 있을 때 사용합니다.

 

503 Service Unavailable

서버가 과부하 상태이거나 요청을 처리 할 수 없음을 의미합니다.

유지보수 혹은 서버 점검을 위해서 서버를 잠시 막을 때도 사용하게 됩니다.

Retry-After헤더를 함께 사용하여 서비스 복구 예상 시간을 포함하는 것이 권고됩니다.

 

504 Gateway Timeout

서버와 클라이언트 사이에 프록시가 존재하고 프록시가 서버에서 응답을 받지 못하는 경우 사용합니다.

502 Bad Gateway와 유사하지만 502는 잘못된 응답을 받았을 때 적합하고 504 Gateway Timeout은 응답을 받지못했을 때 적합합니다.

 

505 HTTP Version Not Supported

요청에 사용된 HTTP 버전은 서버에서 지원되지 않음을 의미합니다.

 

507 Insufficient Storage(WebDAV)

서버에 디스크 공간이 부족한 것을 의미합니다.

 

508 Loop Detected(WebDAV)

서버가 요청을 처리하는 동안 무한 루프에 빠짐을 의미합니다.

 

510 Not Extended

요청에 대한 추가 확장이 필요합니다.

이는 클라이언트 에러에 더 적합하지만 500대 에러로 분류되어 있기 때문에 부적합하다고 판단되어 사용되지 않습니다.

 

511 Network Authentication Required

클라이언트가 네트워크 액세스를 얻기 위해 인증을 받아야 할 필요가 있음을 나타냅니다.

 

 

 

Reference

https://developer.mozilla.org/ko/docs/Web/HTTP/Status

https://httpstatuses.com/

https://evertpot.com/http