글 작성자: nouu

http://www.yes24.com/Product/Goods/15894097

 

그림으로 배우는 HTTP & Network - YES24

이 책은 웹의 근간을 이루는 HTTP를 중심으로 하여 웹, 인터넷 데이터 통신 분야의 기초가 되는 내용들을 다루고 있다. 관련 분야를 배우고자 하는 독자들을 위해 만화 캐릭터와 일러스트를 활용

www.yes24.com

 

해당 서적을 바탕으로 작성하였습니다. 

 

OWASP 웹 해킹과 웹에 대한 구조를 공부하는 와중 HTTP 응답 코드를 다시 상기시켜야 겠다는 마음에 이 글을 작성한다. 

 

 

 

 

상태코드는 서버에서 클라의 요청에 대한 결과를 반환한다. 

클라가 서버를 향해 리퀘스트를 보낼 때 서버에서 그 결과가 어떻게 되었는지 알려주는 것이 상태 코드의 역할이다. 서버가 요청을 정상적으로 처리했는지 그렇지 않았는지 리퀘스트 결과가 에러였는지 알 수 있다. 

 

 

  클래스 설명
1XX Informational 리퀘스트를 받아들여 처리중
2XX Success 리퀘스트를 정상적으로 처리했다.
3XX Redirection 리퀘스트를 완료하기 위해 추가 동작이 필요함
4XX Client Error 서버가 리퀘스트의 이해 불가능
5XX Server Error 서버는 리퀘스트 처리 실패

 

HTTP 상태 코드는 RFC2616 기반으로 40종류가 있으며, 이외에도 RFC4918, 5842, 6585 등의 확장을 포함하면 60종류 이상이 있다. 실제로 사용되고 있는 것은 14종류 정도이다. 

 

 

 

2XX 리퀘스트에 대한 응답 성공(Success)

(1) 200 OK

가장 흔히 볼 수 있는 상태 코드. 클라가 보낸 리퀘스트를 서버가 정상 처리했음을 의미한다.

 

 

 

(2) 204 No Content

해당 상태 코드는 리퀘스트를 받아서 처리하는 데 성공했지만 리스폰스에 바디 정보를 포함하지 않는다. 클라이언트에서 서버에 정보를 보내는 것으로 족하며, 클라에 대해 새로운 정보를 보낼 필요가 없는 경우에 사용한다.

 

 

 

(3) 206 Partial content(부분적인? content)

해당 리스폰스 상태 코드는 Range에 의해서 범위가 지정된 리퀘스트에 의해 서버가 부분적인 GET 리퀘스트를 받았음을 나타낸다. 즉 다음과 같은 그림으로 대략적인 이해가 가능하다. 

 

리스폰스에는 Content-Range로 지정된 범위의 정보가 포함되게 된다.

실무적인 부분에서 206 응답 코드를 사용하는 경우는 아직 의문

 

 

 

 

 

 

 

3XX 리다이렉트(Redirection)

3xx 리스폰스는 리퀘스트가 정상적으로 처리를 종료하기 위해 브라우저 측에서 특별한 처리를 수행해야 함을 나타낸다. 

 

 

(1) Moved Permanently(URL 영속적 이동)

해당 리스폰스는 리퀘스트된 리소스에는 새로운 URI가 부여되며 있기 때문에, 이후로는 그 리소스를 참조하는 URI를 사용해야 한다는 것을 나타낸다. 예를들어 https://sports.news.naver.com/index 와 같은 uri를 검색했을 때 마지막 부분에 슬래시(/)를 붙이는 것을 잊은 경우 등이 있다.(https://sports.news.naver.com/index/)

 

 

(2) 302 FOUND "URI는 잠시 다른 장소에 가 있으니 우선 전달했어~"

301 Moved Permantly와 비슷하지만 302의 경우 영구적인 이동이 아닌 어디까지나 일시적인 것이다. 

 

 

(3)303 See Other

해당 리스폰스는 리퀘스트에 대한 리소스는 다른 URI에 있기 때문에 GET 메소드를 사용해서 얻어야 한다는 것을 나타낸다. 302 Found와 기능이 비슷하지만, 리다이렉트 장소를 GET 메소드로 얻어야 한다는 명확한 지침이 있다.

 

 

 

 

 

 

4XX 클라 에러

4XX는 클라이언트의 요청 원인으로 에러가 발생했음을 나타낸다. 

 

 

(1) 400 Bad Request

이 리스폰스는 리퀘스트 구문이 잘못되었음을 나타낸다. 이 에러가 발생한 경우에 리퀘스트 내용을 재검토하고 나서 재송신할 필요가 있다. 

 

(2) 401 Unauthorizaed

해당 응답 코드는 송신한 리퀘스트에 HTTP 인증(BASIC 인증, DIGEST 인증) 정보가 필요하다는 것을 나타내고 있다. 또한 이미 한번 리퀘스트가 이루어진 경우에 유저 인증에 실패했음을 표시한다. 401을 포함하는 리스폰스를 되돌리는 경우 리퀘스트 된 리소스에 적용되는 challenge를 포함한 WWW-Authenticate 헤더 필드를 포함할 필요가 있다. 

 

 

 

(3) 403 Forbidden

리퀘스트된 리소스의 액세스가 거부되었음을 나타낸다. 서버 측은 거부의 이유를 분명히 할 필요가 있다. 이유를 명확하게 하는 경우에 엔티티 바디에 기재해서 유저 측에 표시한다.

403이 발생한 원인은 다음과 같다. 1. 403이 발생한 원인으로는 파일 시스템의 퍼미션이 부여되지 않은 경우 2. 액세스 권한에 대한 문제

 

(4) 404 Not Found (자주 보이는 응답 코드 '해당 리소스는 서버에 없어요 ㅠㅠ')

이 리스폰스는 리퀘스트한 리소스가 서버상에 없다는 것을 나타낸다. 이 외에도 서버 측에 해당 리퀘스트를 거부하고 싶은 이유를 분명히 하고 싶지 않을 경우 이용할 수 있다. 

 

 

5XX 서버 에러(Server Error)

5XX 리스폰스는 서버 원인으로 에러가 발생하고 있음을 뜻한다. 

 

 

(1) 500 Internal Server Error(내부 서버 에러)

이 리스폰스는 서버에서 리퀘스트를 처리하는 도중 에러가 발생했음을 뜻한다. 웹 어플리케이션에 에러가 발생한 경우나 일시적인 경우도 있다.

 

(2) 503 Service Unavaliable(서비스 사용불가능 '서버가 바빠 ㅠ')

해당 리스폰스는 일시적으로 서버가 과부하 상태거나 점검중이기 때문에 현재 리퀘스트를 처리할 수 없음을 나타낸다. 이 상태가 해소되기까지 시간이 걸리는 경우 Retry-After 헤더 필드에 따라서 클라에 전달하는 것이 바람직하다. 

 

 

 

상태 코드는 현재 상황과 불일치할 수도 있습니다. 

흔히 있는 상황이며, 웹 어플에서 어플리케이션 에러가 발생한 경우에도 상태 코드로 200 ok가 되돌아오는 경우가 있다.