우리는 HTTP 상태코드에는 크게 1xx, 2xx, 3xx, 4xx, 5xx 이렇게 다섯 카테고리로 구분하며,
- 1xx 는 단순 정보 제공
- 2xx 는 클라이언트의 요청을 정상적으로 처리 (OK)
- 3xx 는 리다이렉트
라는 것을 배웠다.
오늘은 4xx 와 5xx 에 대한 상태코드를 배운다.
1. Client Error (4xx)
400 Bad Request
클라이언트의 에러를 표현하는 가장 대표적인 응답 상태 코드이다. 웹서버가 클라이언트의 요청을 이해하지 못했을때 전달하는 메시지이다.
대체로 클라이언트의 요청 형태(format) 가 잘못 되었거나, 사이즈가 너무 크거나 하는 등.. 이러한 경우 400 Bad Request 가 반환된다.
401 Unauthorized
"401 Unauthorized" 응답 코드는 클라이언트에게 인증을 요구할때 사용된다.
클라이언트가 요청한 컨텐츠의 접근권한을 확인하려는 목적으로 전달된다.
"401 Unauthroized" 응답 코드와 함께 "WWW-Authenticate" 헤더에 인증 방식을 표시하여 같이 전달한다.
우리 이전 요청헤더 강좌 중에 "Authorization"을 다룰때 언급한적이 있는데 이 헤더에 대한 내용을 자세히 알고 싶다면 여기 를 클릭하자.
402 Payment Required
HTTP 에서는 "402 Payment Required" 에 대해 명세하고 있으나, 현재는 미래를 위해 예약해 둔 상태코드이다.
응답 코드에 연결된 메시지(Payment Required) 처럼 디지털 캐시나 마이크로 페이먼트와 같은 경우에 지불정보를 요구하는 형태로 사용된다고 하지만.. 아직 실무에서 확인해 본 바는 없다.
구글 개발 API 에서 특정 개발자가 하루 임계 요청량을 초과한 경우 이 코드를 반환하는 형태고 사용된다고는 한다.
403 Forbidden
클라이언트의 요청 형태등에서 잘못된 것은 없다. 다만, 요청한 컨텐츠에 접근할 수 있는 권한이 없는 경우 이 응답 상태코드를 받게 된다.
가령 특정 디렉토리 또는 컨텐츠에 접근할 수 있는 권한이 없는 사용자가 해당 컨텐츠를 요구한 경우가 이에 해당된다.
401 응답코드와 비슷하지만, 403의 경우에는 요청에 Authroization 헤더가 존재하지 않는다. 때문에 웹서버는 사용자의 정보를 요구하지 않고 바로 "403 Forbidden" 코드를 반납한다.
404 Not Found
웹서버에 존재하지 않는 컨텐츠를 요청한 경우 반환되는 메시지이다.
4xx 코드 중에서 실제 가장 많이 확인해 볼수 있는 응답 상태 코드이기도 하다.
405 Method Not Allowed
클라이언트가 사용한 HTTP 요청 메소드(Method) 가 웹서버에서 허용되지 않았음을 의미한다. 이 상태코드 메시지와 함께 전달되는 Allow 헤더에 허용된 메서드들에 대해 표시된다.
아래 HTTP 요청/응답헤더를 살펴보자.
클라이언트가 DELETE 라는 요청 방식을 사용했으나, 웹서버는 이를 허용하지 않았다.
405 응답코드를 반환했고, Allow 헤더를 이용해서 현재 웹서버에서 사용가능한 메소드 들을 알려준다.
406 Not Acceptable
클라이언트는 웹서버로 요청을 할 때, 자신이 지원하는 여러정보들을 함께 보낸다.
브라우저로 표현할 수 있는 컨텐츠 타입, 언어, 인코딩 타입등등..
웹서버가 클라이언트의 요청을 처리하여 응답할때 이러한 클라이언트의 정보를 참고하게 되는데, 자신이 응답하는 컨텐츠가 클라이언트가 지원하는 형태에 맞지 않을때 406 응답 상태 코드를 사용하게 된다.
407 Proxy Authentication Required
이 코드는 클라이언트가 먼저 프록시로부터 인증을 받아야 한다는 것을 의미한다.
클라이언트가 요청하는 컨텐츠에 대해서, 프록시로부터 인증을 먼저 받아야만 정상 처리가 가능하다는 뜻이다.
프록시 서버가 전달하는 응답코드이며, Proxy-Authenticate 헤더를 포함하여 어떤 인증방식을 이용할 것인지를 클라이언트에게 알린다.
클라이언트는 Proxy-Authenticate 헤더와 함께 407 응답코드를 받게 되면 이후 요청에서 Proxy-Authorization 헤더에 인증 정보를 포함하여 전달하게 된다.
408 Request Timeout
클라이언트의 요청을 웹서버가 기다리다가 더이상 기다리지 못하게 되면, 이 응답코드를 보낸다.
예를 들어 다음과 같은 상황을 가정하자.
정상적인 경우..
클라이언트가 Expect 헤더를 이용하여 웹서버로 부터 데이터를 보내도 되는지 여부를 묻는다. 웹서버에서 처리 가능한 데이터일 경우 100 Continue 응답 상태 코드를 전달하여 데이터를 받아 처리한다.
비정상인 경우...
클라이언트이 Expect 헤더를 보고 100 Continue 응답 코드를 보냈으나, 클라이언트가 이후 데이터를 보내지 않은 경우 웹서버는 자신의 Timeout 시간동안 기다려보고 데이터가 오지 않으면 "408 Request Timeout" 메시지를 반환한다.
409 Conflict
웹서버에 있는 컨텐츠를 누군가 먼저 요청하고 작업중인데 다른 사용자가 같은 컨텐츠에 대한 작업을 요청하면 "409 Conflict" 메시지를 후 사용자에게 전달한다.
예를 들어 PUT 방식으로 어떤 컨텐츠에 대한 변경을 진행하고 있는 중... 다른 사용자가 같은 작업을 하려 하는 경우가 이에 해당된다.
410 Gone
요청한 컨텐츠가 더이상 사용가능하지 않은 경우 반환되는 코드이다. 약간 404 Not Found 응답 코드가 의미적으로 비슷하다.
다만, 차이점은 404는 임시적인 상태인 경우의 메시지이고.. 410은 지속적인 상태의 메시지이다.
다시 말하면.. 404 응답코드는 현재는 없는 컨텐츠이지만, 이후 존재할 가능성이 있다는 뜻이고, 410은 현재도 없고, 앞으로도 없을 것이라는 의미이다.
검색엔진이 410 Gone 코드를 받게 되면 자신의 색인 목록에서 이를 삭제해야 한다.
그러나 대부분의 경우 색인목록에서의 삭제를 요구하지 않아서 410보다는 404 코드가 많이 사용되긴 한다.
411 Length Required
클라이언트가 유효한 Content-Length 헤더를 갖지 않은 경우 웹서버는 요청을 거절하면서 이 응답 상태 코드를 사용할 수 있다.
412 Precondition Failed
웹서버 또는 프록시서버가 클라이언트의 요청을 처리하기 위해 어떤 조건(If-Match와 같은)을 요구하는 경우가 있을 수 있는데.. 이 정보가 웹 서버 기준에서 충족하지 않는 경우 이 응답코드가 반환된다.
413 Request Entity Too Large
웹서버에서 수용할 수 있는 메시지 바디의 사이즈보다 큰 데이터가 들어온 경우 이 응답 상태 코드를 반환한다.
414 Request-URI Too Long
413 코드와 비슷한 형태의 에러 메시지이다. 다만, 414 응답 코드는 URI 길이가 웹서버에서 처리 할 수 있는 범위를 넘어 선 경우 반환된다.
415 Unsupported Media Type
요청 메시지 바디의 미디어 타입을 웹서버에서 지원하지 않는 경우 반환되는 코드이다.
예를 들어, 클라이언트가 이미지 파일을 하나 업로드 한다. 이때 이미지는 image/svg+xml 인 경우.. svg+xml 형태의 이미지를 웹서버에서 지원하지 않는 경우가 해당된다.
416 Requested Range Not Satisfiable
앞서 Range 헤더를 이용해서 클라이언트는 이어받기를 할 수 있다는것을 배운바 있다.
(Range 헤더에 대한 상세 내용은 여기 를 클릭하여 확인 가능하다. )
클라이언트가 대용량의 파일을 다운로드하다가 중간에 끊어지게 되면.. 마지막 전송받은 바이트(Bytes) 부터 다시 요청하여 이어 받기를 한다.
이때 다시 전달받을 용량의 시작점을 Range 헤더에 명시하게 되는데..
클라이언트가 이 정보를 잘못 명시한 경우 웹서버는 416 응답 상태 코드를 반환한다.
417 Expectation Failed
클라이언트가 요청시 Expect 헤더에 클라이언트가 예상하는 정보를 담아 보낼수 있다.
우리가 엎서 배운 것으로는 Expect: 100-continue 가 있다.
이와 같이 클라이언트가 예상하는 어떤 정보를 웹서버가 만족하지 못할 경우 417 응답 상태코드를 반환한다.
426 Upgrade Required
앞서 Upgrade 헤더에 대해 배운 적이 있다. ( 여기 를 클릭하여 Upgrade 의 상세 내용을 확인할 수 있다.)
클라이언트가 HTTP 를 TLS 등과 같이 보안 프로토콜로 변환하고자 할 경우 Upgrade 헤더를 사용한다. 비슷하지만.. 426 Upgrade Required 응답 상태 코드는 서버가 보안채널을 통한 통신을 하고자 할때 클라이언트에게 전달하는 상태 코드인 것이다.
2. Server Error (5xx)
500 Internal Server Error
500 응답 코드는 일반적인 서버의 문제를 알리는 상태 코드이다. 웹서버가 추가적으로 에러에 대한 상세한 내용을 전하는 경우 응답 메시지 바디를 이용한다.
501 Not Implemented
요청 메소드를 전혀 웹서버가 이해하지 못할때 반환되는 코드이다. 흔히 새로운 기능의 웹기반 API 에서 발생되는 에러 코드의 종류이다.
클라이언트의 요청 메소드에는 전혀 문제가 없으나, 서버가 이를 정상적으로 처리하지 못하는 경우인것이다. (서버 문제)
502 Bad Gateway
프록시 서버가 유효하지 않은 응답을 웹서버로부터 받게 되면 "502 Bad Gateway" 메시지를 반환하게 된다.
예로 다음과 같은 경우가 502 Bad Gateway 가 발생하는 상태이다.
HTTP 에서는 "402 Payment Required" 에 대해 명세하고 있으나, 현재는 미래를 위해 예약해 둔 상태코드이다.
응답 코드에 연결된 메시지(Payment Required) 처럼 디지털 캐시나 마이크로 페이먼트와 같은 경우에 지불정보를 요구하는 형태로 사용된다고 하지만.. 아직 실무에서 확인해 본 바는 없다.
구글 개발 API 에서 특정 개발자가 하루 임계 요청량을 초과한 경우 이 코드를 반환하는 형태고 사용된다고는 한다.
403 Forbidden
클라이언트의 요청 형태등에서 잘못된 것은 없다. 다만, 요청한 컨텐츠에 접근할 수 있는 권한이 없는 경우 이 응답 상태코드를 받게 된다.
가령 특정 디렉토리 또는 컨텐츠에 접근할 수 있는 권한이 없는 사용자가 해당 컨텐츠를 요구한 경우가 이에 해당된다.
401 응답코드와 비슷하지만, 403의 경우에는 요청에 Authroization 헤더가 존재하지 않는다. 때문에 웹서버는 사용자의 정보를 요구하지 않고 바로 "403 Forbidden" 코드를 반납한다.
404 Not Found
웹서버에 존재하지 않는 컨텐츠를 요청한 경우 반환되는 메시지이다.
4xx 코드 중에서 실제 가장 많이 확인해 볼수 있는 응답 상태 코드이기도 하다.
405 Method Not Allowed
클라이언트가 사용한 HTTP 요청 메소드(Method) 가 웹서버에서 허용되지 않았음을 의미한다. 이 상태코드 메시지와 함께 전달되는 Allow 헤더에 허용된 메서드들에 대해 표시된다.
아래 HTTP 요청/응답헤더를 살펴보자.
405 응답코드를 반환했고, Allow 헤더를 이용해서 현재 웹서버에서 사용가능한 메소드 들을 알려준다.
406 Not Acceptable
클라이언트는 웹서버로 요청을 할 때, 자신이 지원하는 여러정보들을 함께 보낸다.
브라우저로 표현할 수 있는 컨텐츠 타입, 언어, 인코딩 타입등등..
웹서버가 클라이언트의 요청을 처리하여 응답할때 이러한 클라이언트의 정보를 참고하게 되는데, 자신이 응답하는 컨텐츠가 클라이언트가 지원하는 형태에 맞지 않을때 406 응답 상태 코드를 사용하게 된다.
407 Proxy Authentication Required
이 코드는 클라이언트가 먼저 프록시로부터 인증을 받아야 한다는 것을 의미한다.
클라이언트가 요청하는 컨텐츠에 대해서, 프록시로부터 인증을 먼저 받아야만 정상 처리가 가능하다는 뜻이다.
프록시 서버가 전달하는 응답코드이며, Proxy-Authenticate 헤더를 포함하여 어떤 인증방식을 이용할 것인지를 클라이언트에게 알린다.
클라이언트는 Proxy-Authenticate 헤더와 함께 407 응답코드를 받게 되면 이후 요청에서 Proxy-Authorization 헤더에 인증 정보를 포함하여 전달하게 된다.
408 Request Timeout
클라이언트의 요청을 웹서버가 기다리다가 더이상 기다리지 못하게 되면, 이 응답코드를 보낸다.
예를 들어 다음과 같은 상황을 가정하자.
정상적인 경우..
클라이언트가 Expect 헤더를 이용하여 웹서버로 부터 데이터를 보내도 되는지 여부를 묻는다. 웹서버에서 처리 가능한 데이터일 경우 100 Continue 응답 상태 코드를 전달하여 데이터를 받아 처리한다.
비정상인 경우...
클라이언트이 Expect 헤더를 보고 100 Continue 응답 코드를 보냈으나, 클라이언트가 이후 데이터를 보내지 않은 경우 웹서버는 자신의 Timeout 시간동안 기다려보고 데이터가 오지 않으면 "408 Request Timeout" 메시지를 반환한다.
409 Conflict
웹서버에 있는 컨텐츠를 누군가 먼저 요청하고 작업중인데 다른 사용자가 같은 컨텐츠에 대한 작업을 요청하면 "409 Conflict" 메시지를 후 사용자에게 전달한다.
예를 들어 PUT 방식으로 어떤 컨텐츠에 대한 변경을 진행하고 있는 중... 다른 사용자가 같은 작업을 하려 하는 경우가 이에 해당된다.
410 Gone
요청한 컨텐츠가 더이상 사용가능하지 않은 경우 반환되는 코드이다. 약간 404 Not Found 응답 코드가 의미적으로 비슷하다.
다만, 차이점은 404는 임시적인 상태인 경우의 메시지이고.. 410은 지속적인 상태의 메시지이다.
다시 말하면.. 404 응답코드는 현재는 없는 컨텐츠이지만, 이후 존재할 가능성이 있다는 뜻이고, 410은 현재도 없고, 앞으로도 없을 것이라는 의미이다.
검색엔진이 410 Gone 코드를 받게 되면 자신의 색인 목록에서 이를 삭제해야 한다.
그러나 대부분의 경우 색인목록에서의 삭제를 요구하지 않아서 410보다는 404 코드가 많이 사용되긴 한다.
411 Length Required
클라이언트가 유효한 Content-Length 헤더를 갖지 않은 경우 웹서버는 요청을 거절하면서 이 응답 상태 코드를 사용할 수 있다.
412 Precondition Failed
웹서버 또는 프록시서버가 클라이언트의 요청을 처리하기 위해 어떤 조건(If-Match와 같은)을 요구하는 경우가 있을 수 있는데.. 이 정보가 웹 서버 기준에서 충족하지 않는 경우 이 응답코드가 반환된다.
413 Request Entity Too Large
웹서버에서 수용할 수 있는 메시지 바디의 사이즈보다 큰 데이터가 들어온 경우 이 응답 상태 코드를 반환한다.
414 Request-URI Too Long
413 코드와 비슷한 형태의 에러 메시지이다. 다만, 414 응답 코드는 URI 길이가 웹서버에서 처리 할 수 있는 범위를 넘어 선 경우 반환된다.
415 Unsupported Media Type
요청 메시지 바디의 미디어 타입을 웹서버에서 지원하지 않는 경우 반환되는 코드이다.
예를 들어, 클라이언트가 이미지 파일을 하나 업로드 한다. 이때 이미지는 image/svg+xml 인 경우.. svg+xml 형태의 이미지를 웹서버에서 지원하지 않는 경우가 해당된다.
416 Requested Range Not Satisfiable
앞서 Range 헤더를 이용해서 클라이언트는 이어받기를 할 수 있다는것을 배운바 있다.
(Range 헤더에 대한 상세 내용은 여기 를 클릭하여 확인 가능하다. )
클라이언트가 대용량의 파일을 다운로드하다가 중간에 끊어지게 되면.. 마지막 전송받은 바이트(Bytes) 부터 다시 요청하여 이어 받기를 한다.
이때 다시 전달받을 용량의 시작점을 Range 헤더에 명시하게 되는데..
클라이언트가 이 정보를 잘못 명시한 경우 웹서버는 416 응답 상태 코드를 반환한다.
417 Expectation Failed
클라이언트가 요청시 Expect 헤더에 클라이언트가 예상하는 정보를 담아 보낼수 있다.
우리가 엎서 배운 것으로는 Expect: 100-continue 가 있다.
이와 같이 클라이언트가 예상하는 어떤 정보를 웹서버가 만족하지 못할 경우 417 응답 상태코드를 반환한다.
426 Upgrade Required
앞서 Upgrade 헤더에 대해 배운 적이 있다. ( 여기 를 클릭하여 Upgrade 의 상세 내용을 확인할 수 있다.)
클라이언트가 HTTP 를 TLS 등과 같이 보안 프로토콜로 변환하고자 할 경우 Upgrade 헤더를 사용한다. 비슷하지만.. 426 Upgrade Required 응답 상태 코드는 서버가 보안채널을 통한 통신을 하고자 할때 클라이언트에게 전달하는 상태 코드인 것이다.
2. Server Error (5xx)
500 Internal Server Error
500 응답 코드는 일반적인 서버의 문제를 알리는 상태 코드이다. 웹서버가 추가적으로 에러에 대한 상세한 내용을 전하는 경우 응답 메시지 바디를 이용한다.
501 Not Implemented
요청 메소드를 전혀 웹서버가 이해하지 못할때 반환되는 코드이다. 흔히 새로운 기능의 웹기반 API 에서 발생되는 에러 코드의 종류이다.
클라이언트의 요청 메소드에는 전혀 문제가 없으나, 서버가 이를 정상적으로 처리하지 못하는 경우인것이다. (서버 문제)
502 Bad Gateway
프록시 서버가 유효하지 않은 응답을 웹서버로부터 받게 되면 "502 Bad Gateway" 메시지를 반환하게 된다.
예로 다음과 같은 경우가 502 Bad Gateway 가 발생하는 상태이다.
- 1~3번까지는 TCP 연결 생성 과정이다. (3-way 핸드쉐이크)
- 4번은 프록시 서버와 정상적으로 TCP 연결을 맺은 다음 HTTP 요청을 한다.
- 프록시 서버는 클라이언트의 요청을 전달하기 위해 웹서버와 TCP 연결을 맺는다.
(5~7번 과정) - 하지만 웹서버에서는 80포트는 열려있으나 HTTP 데몬이 아니다. 즉, HTTP 요청을 정상적으로 처리할 수 없는 상태이다. 따라서 8번과 같이 클라이언트의 HTTP 요청이 전달되면 9번과 같이 세션을 끊는다.
- 프록시 서버는 웹서버와 TCP 세션은 맺었으나 요청에 대한 응답을 받지 못했기에 클라이언트에게 "502 Bad Gateway" 메시지를 전달한다.
프록시 서버 입장에서 웹서버가 TCP 세션은 열려있으나 HTTP 처리가 되지 않는 경우..
세션이 끊어지거나 HTTP 가 아닌 다른 프로토콜의 응답을 받게 되는 경우 웹서버는 502 상태 코드를 반환한다.
503 Service Unavailable
웹서버가 클라이언트의 요청을 정상적으로 처리할 수 없는 상태인 경우이다.
물리적으로 웹서버는 살아 있으나, 웹서비스 데몬이 다운되었거나 부하가 심해서 처리가 불가능한 상태이거나 한 경우가 이에 해당된다.
다음과 같은 경우를 예로 살펴 보자.
- 1~3번 과정을 통해 프록시 서버와 TCP 연결을 수립한다.
- 4번 HTTP 요청을 보낸다.
- 프록시 서버는 클라이언트의 요청을 전달하기 위해서 웹서버에 TCP 연결을 하려고 시도한다. 하지만, 웹 서비스 포트가 다운되어 있어서 접속이 불가하다.
- 프록시 서버는 클라이언트에게 503 상태 메시지를 전달한다.
프록시 서버가 웹서버로 클라이언트의 요청을 전달하기 위해서 TCP 연결을 시도 했으나, 웹서버의 데몬이 다운되어 연결이 되지 못한 경우, 서비스가 불가하기 때문에 "503 Service Unavailable" 상태코드를 전달한다.
504 Gateway Timeout
클라이언트의 요청을 프록시 서버가 웹서버로 전달한 후... 이정 시간이 지났는데도 응답을 받지 못하게 되면.. 프록시는 마냥 기다리기만 하지 않는다.
일정 시간이 지나도록 요청에 대한 응답이 없다면, 서비스가 정상적이지 못하다고 판단하고 클라이언트에게 "504 Gateway Timeout" 메시지를 반환한다.
다음의 경우와 같다.
- 8번과 같이 클라이언트의 요청을 정상적으로 웹서버에게 전달했으나 이에 대한 응답이 없다.
- 그렇다면 일정시간 후 프록시는 클라이언트에게 504 Gateway Timeout 을 보낸다.
505 Version Not Supported
클라이언트의 HTTP 요청 버젼을 웹서버가 지원하지 못하는 경우이다.
웹서버는 HTTP 0.9 를 지원하고 있는데, 느닷없이 클라이언트가 HTTP 1.1 로 요청한 경우 처리가 불가능하기 때문에 "505 Version Not Supported" 를 반환한다.
뭐, 요새가 어떤 세상이랴~~~~..
현업에서 505 상태코드는 본적이 없긴 하다. ^^
여기까지 해서 HTTP 상태 코드를 모두 마친다.
아무래도 5xx 코드는 설명을 위해 노력을 좀 한 편이긴 하다. 엔지니어들이 5xx 에러코드를 만나는 경우 아~~ 이런 경우겠구나.. 하고 문제접근을 하는게 중요하기 때문이다.
다음 시간 부터는 가속과 보안에 대해 이야기 하도록 한다.
끝!!!
댓글 없음:
댓글 쓰기