Infrahttp network

4장 결과를 전달하는 HTTP 상태 코드

⏱ 읽기 소요 시간: 9 분

그림으로 배우는 HTTP & Network
(우에노 센 저 / 이병억 역 )
을 읽고 정리한 내용입니다.

HTTP 상태 코드란 무엇인가?

클라이언트가 HTTP 리퀘스트를 보낸 결과
(서버가 정상적으로 처리되었는지 또는 에러가 발생했는지)를 알려주는 것을 말한다.

상태 코드는 서버로부터 리퀘스트를 전달한다

리스폰스 상태 코드로 리퀘스트의 처리 결과를 알 수 있다.
상태 코드의 역할: 클라이언트가 서버를 향해 리퀘스트를 보낼 때, 서버에서 그 결과가 어떻게 되었는지 알려주는 것

  • 숫자 첫 번째 자리: 리스폰스의 클래스를 의미
  • 나머지 2자리: 분류가 없다.

상태 코드 클래스

  • 1xx (Informational): 리퀘스트를 받아들여 처리중
  • 2xx (Success): 리퀘스트를 정상적으로 처리했음
  • 3xx (Redirection): 리퀘스트를 완료하기 위해서 추가 동작이 필요
  • 4xx (Client Error): 서버는 리퀘스트 이해 불가능
  • 5xx (Server Error): 서버는 리퀘스트 처리 실패

2xx 성공 (Success)

4.2.1. 200 OK: 클라이언트가 보낸 리퀘스트를 서버가 정상적으로 처리하였음을 의미

4.2.2. 204 No Content

  • 서버에서 리퀘스트를 받아서 처리하는 데는 성공했지만, 리스폰스에 엔티티 바디를 포함하지 않는다.
  • 클라이언트에서 서버에 정보를 보내고, 서버측에서는 돌려줄 리소스가 없는 경우 사용한다.

4.2.3. 206 Partial Content

  • 클라이언트에서 일부만 가지고 싶다고 서버에 리퀘스트한 경우를 말한다.
  • Range에 의해서 범위가 지정된 리퀘스트에 의해서 서버가 부분적인 GET 리퀘스트를 받았음을 나타낸다.
  • 리스폰스에는 Content-Range로 지정된 범위의 엔티티가 포함되게 된다.

3xx 리다이렉트 (Redirection)

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

4.3.1. 301 Moved Permanently

북마크를 변경하기 위한 리퀘스트를 보낸 경우
이 때의 리스폰스는 리퀘스트된 리소스에 새로운 URI가 부여되어 있기 때문에
이후로는 그 리소스를 참조하는 URI를 사용해야 한다는 것을 나타내고 있다.

따라서, 북마크하고 있는 경우,
Location 헤더 필드에서 가리키고 있는 URI에 북마크를 다시 하는 게 좋다는 것을 나타내고 있다.

ex) 디렉토리를 지정했을 때 마지막 부분에 슬래시(/)를 잊은 경우

request
1
http://example.com/sample

4.3.2. 302 Found

리퀘스트된 리소스에 새로운 URI가 할당되어 있기 때문에 그 URI를 참조해 주길 바란다는 의미를 나타낸다.
301과 비슷하지만, 302의 경우에는 영구적인 이동이 아니라 일시적인 이동을 의미한다.
결국, 이동하는 곳의 URI는 앞으로 이동될 가능이 있다.

ex) 북마크하고 있는 경우, 301의 경우와 같이 북마크를 변경하지 않는다.
302를 돌려준 페이지에 대해서 북마크해야 한다.

4.3.3. 303 See Other

이 리스폰스는 리퀘스트에 대한 리소스는 다른 URI에 있기 때문에 GET 메소드를 사용해서 얻어야 한다는 것을 나타낸다.
302와 같은 기능이지만, 리다이렉트 장소를 GET 메소드로 얻어야 한다고 명확하게 되어 있는 점이 302와 다르다.

ex) POST 메소드로 액세스한 CGI 프로그램을 실행한 후,
처리 결과를 별도의 URI에 GET 메소드로 리다이렉트 시키고 싶은 경우 등에 303이 사용되고 있다.
302 Found라도 같은 일이 가능하지만, 303을 사용하는 것이 바람직하다.

301, 302, 303 리스폰스 코드가 되돌아 오면,
대부분 브라우저에서는 POST를 GET으로 바꾸어서 리퀘스트의 엔티티 바디를 삭제하고 리퀘스트를 자동적으로 재송신하도록 되어 있다.
301, 302 사양은 POST를 GET 메소드로 바꾸는 것을 금지하고 있지만, 구현은 이렇게 되어 있는 경우가 대부분이다.

4.3.4. 304 Not Modified

클라이언트가 조건부 리퀘스트를 했을 때 리소스에 대한 액세스는 허락하지만,
조건이 충족되지 않음을 표시하고 있다.

4.3.5. 307 Temporary Redirect

307에서는 브라우저 사양에 따라 POST에서 GET으로 치환을 하지 않는다.
다만, 브라우저마다 리스폰스를 처리하는 동작이 다를 경우가 있다.

4xx 클라이언트 에러 (Client Error)

4xx 리스폰스는 클라리언트의 원인으로 에러가 발생했음을 의미

4.4.1. 400 Bad Request

리퀘스트 구문이 잘못되었음을 나타낸다.
-> 이 에러 발생시, 내용을 재검토한 후 재송신할 필요가 있다.
브라우저는 이 400을 200 OK와 같이 취급한다.

4.4.2. 401 Unauthorized

  • 리퀘스트 송신 -> 최초의 401 리스폰스의 경우

    이 페이지는 인증이 필요합니다

  • 두 번째 401 리스폰스의 경우(이미 리퀘스트가 Authorization Required를 포함하고 있는 경우)

    인증 실패 했습니다

이 리스폰스는 송신한 리퀘스트에 HTTP 인증(BASIC 인증, DIGEST 인증) 정보가 필요하다는 것을 나타낸다.
또한, 이미 1번 리퀘스트가 이루어진 경우에는 유저 인증에 실패했음을 표시

401을 포함한 리스폰스를 되돌리는 경우

리퀘스트 된 리소스에 적용된 challenge를 포함한 WWW-Authenticate 헤더 필드를 포함할 필요가 있다.
브라우저에서 처음 401 리스폰스를 받은 경우: 인증을 위한 다이얼로그를 표시

4.4.3. 403 Forbidden

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

403이 발생한 원인: 파일 시스템의 퍼미션이 부여되지 않은 경우와
액세스 권한에 문제(허가되지 않은 송신 IP 주소의 액세스 등)가 있는 것을 예로 들 수 있다.

5xx 서버 에러 (Server Error)

리퀘스트한 리소스는 서버 상에 없다는 의미
서버 측에 해당 리퀘스트를 거부하고 싶은 이유를 분명히 하고 싶은 경우와 그렇지 않은 경우에도 이용할 수 있다.

4.5.1. 500 Internal Server Error

서버 원인으로 에러가 발생하고 있음을 의미한다.
웹 애플리케이션에 에러가 발생한 경우 or 일시적인 경우도 있다.

4.5.2. 503 Service Unavailable

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

상태 코드가 현재 상황과 불일치할 수 있다.
흔히 있는 상황으로 웹 애플리케이션에서 애플리케이션 에러가 발생한 경우에도
상태 코드로는 200 OK가 되돌아오는 경우가 있다.

Share