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

해당 내용은 그림으로 배우는 Http&Network Basic 책내용을 정리한것 입니다.

---

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

• 클라이언트가 서버를 향해 요청을 보낼 때 서버에서 그 결과가 어떻게 됐는지 알려주는 것이 상태코드의 역할 이다.
• 서버가 요청을 정상적으로 처리했는지 결과가 에러였는지를 알수 있다.
• 상태코드는 3자리 숫자와 설명으로 나타낸다.
• 숫자의 첫번째 자리는 리스폰스의 클래스를 의미하고 나머지는 분류가없다.

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

2. 2xx 성공(Success)

• 2xx 응답은 요청이 정상으로 처리되었음을 나타낸다.

1. 200 OK
   • 응답에서 상태코드와 되돌아오는 정보는 메소드에따라 다르다.
   • GET 의 경우 요청된 리소스의 대응하는 엔티티가 응답으로 보내진다
   • HEAD의 경우 요청된 리소스에 대응하는 엔티티 헤더 필드가 메세지 바디를 동반하지 않고 응답으로 보내진다.
2. 204 No Content
   • 처리에는 성공했지만 응답에 엔티티 바디를 포함하지 않는다.
   • 어떠한 엔티티 바디를 되돌려 보내서도 안된다.
   • 204 응답을 수신했어도 화면이 변하는 일은 없다.
   • 클라이언트는 서버에 정보를 보내는것으로 만족하고, 클라이언트에 대해 새로운 정보를 보낼 필요가 없는경우에 사용된다.
3. 206 Partial Content
   • Range에 의해서 범위가 지정된 요청에 관해서 서버가 부분적 GET 요청을 받았음을 나타내다.
   • 응답에는 Cotent-Range로 지정된 범위의 엔티티가 포함된다.

3. 3xx 리다이렉트(Redirection)

• 3xx 응답은 요청이 정상적으로 처리를 종료하기 위해 브라우저에서 특별한 처리를 수행해야함을 나타낸다.

1. 301 Moved Permanently
   • 요청된 리소스에는 새로운 URI가 부여되어 있기 때문에 이후에는 그 리소스를 참조하는 URI를 사용해야 한다는 것을 나타낸다.
   • 북마크 하고 있는 경우에는 Location 헤더필드에서 가리키는 URI에 북마크를 다시 하는게 좋다는것을 나타낸다.
   • 301이 발생하는 상황으로는 요청과 같이 디렉토리를 지정했을때 마지막 부분에 슬래시(/) 를 붙이는 것을 잊는 경우등이 있다.
2. 302 Found
   • 요청된 리소스에 새로운 URI가 할당되어 새로운 URI를 참조해주길 바란다는 의미를 나타낸다.
   • 301와 비슷하지만 302는 영구적인 이동이 아닌 일시적임을 나타낸다.
   • 이동하는 곳의 URI는 앞으로 이동될 가능성이 있다.
3. 303 See Other
   • 요청에 대한 리소스는 다른 URI에 있기때문에 GET 메소드르 사용해서 얻어야 한다는 것을 나타낸다.
   • 이건은 302와 같은 기능이지만, 리다이렉트 장소를 GET 메소드로 얻어야 한다고 명확히 한다.
   • POST 메소드로 요청한 프로그램 실행후 처리결과를 별도의 URI에 GET 메소드로 리다이렉트 시키고싶은 경우등에 303을 사용한다.

• 301, 302, 303 응답코드가 되돌아오면 대부분 브라우저는 POST를 GET 으로 바꾸어서 요청의 엔티티바디를 삭제하고 요청을 자동적으로 재송신하도록 설계되어있다. 301, 302의 사양은 POST 메소드를 GET 메소드로 바꾸는것을 금지하지만, 구현해 놓은것을 보면 대부분 바꾼다.

4. 304 Not Modified
   • 클라이언트가 조건부 요청을 했을때 리소스에 대한 엑세스는 허락하지만, 조건이 충족되지 않았음을 나타낸다.
   • 304를 되돌려 줄경우에는 응답 바디에 어느것도 포함되면 안된다.
5. 307 Temporary Redirect
   • 302와 같은 의미를 지닌다.
   • 302는 POST 로부터 GET 으로 치환이 금지 되어있지만 구현상 그렇지않다.
   • 307은 브라우저 사양에 따라서 POST 에서 GET 으로 치환하지 않는다.
   • 단지, 브라우저 마다 응답을 처리하는 동작이 다른 경우도 있다.

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

• 4xx 응답은 클라이언트의 원인으로 에러가 발생했음을 나타낸다.

1. 400 Bad Request
   • 요청 구분이 잘못되었음을 나타낸다
   • 이 에러가 발생한 경우 요청 내용을 재검토하고 재송신할 필요가있다.
   • 브라우저는 이것을 200 OK 와 같이 취급한다.
2. 401 Unauthorized
   • 송신한 요청에 HTTP 인증(BASIC, DIGEST) 정보가 필요하다는 것을 나타낸다.
   • 이미 1번의 요청이 이루어진 경우 유저인증을 실패했음을 나타낸다.
   • 401을 포함한 응답을 되돌리는 경우 요청된 리소스에 적용되는 challenge를 포함한 WWW-Authenticate 헤더필드를 포함한 필요가있다.
   • 브라우저에서 처음 401 응답을 받은 경우에는 인증을 위한 다이얼로그가 표시된다.
3. 403 Forbidden
   • 요청된 리소스의 접근이 거부되었음을 나타낸다.
   • 서버 측은 거부의 이유를 분명히 해야할 필요가있다.
   • 이유를 명확하게 하는 경우에는 엔티티 바디에 기재하여 되돌려준다.
   • 403의 원인으로는 파일시스템에 권한이 부여되지 않은 경우와 접근권한 문제가 있는것이 대표적이다.
4. 404 Not Found
   • 요청된 리소스가 서버상에 없다는 것을 나타낸다.
   • 그 외에도 서버가 해당 요청을 거부하고 싶은 이유를 분명히 하고 싶지 않은경우 이용할수 있다.

5. 5xx 서버 에러(Server Error)

• 5xx 응답은 서버원인으로 에러가 발생하고 있음을 나타낸다.

1. 500 Internal Server Error
   • 서버에서 요청을 처리하는 도중에 에러가 발생했음을 나타낸다.
   • 웹 애플리케이션에 에러가 발생했거나 일시적인 경우도 있다.
2. 503 Service Unavaliable
   • 일시적으로 서버가 과부하 상태이거나 점검중일때 현재 요청을 처리할수 없음을 나타낸다.
   • 이 상태가 해소되기까지 시간이 걸리는 경우에 Retry-After 헤더필드에 따라 클라이언트에 전달하는 것이 바람직하다.

상태코드가 현재 상황과 불일치할 수도 있다.
응답으로 되돌아오는 상태코드의 대부분은 유저가 다른 내용을 알기 어렵게 되어있다.
애플리케이션 에러가 발생한 경우에도 상태코드가 200 OK 로 되돌아오는 경우도 있다.