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

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

상태 코드의 역할

클라이언트가 서버를 향해 리퀘스트를 보낼 때 서버에서 그 결과가 어떻게 처리되었는지 알려주는 것.

 

상태 코드 클래스

클래스 설명

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

 

2xx 성공

2xx 리스폰스는 리퀘스트가 정상 처리되었음을 나타냅니다.

200 OK

200 리스폰스는 리퀘스트가 정상 처리되었음을 나타냅니다.

GET메소드의 경우 리퀘스트된 리소스에 대응하는 엔티티가 리스폰스로 보내지고

HEAD메소드의 경우 리퀘스트된 리소스에 대응하는 엔티티 헤더 필드가 메시지 바디를 동반하지 않고 리스폰스로 되돌아옵니다.

204 No Content

서버가 리퀘스트를 받아서 처리하는 데는 성공했지만 리스폰스에 엔티티 바디를 포함하지 않으며 어떠한 엔티티 바디를 되돌려 주어도 안됩니다.

이는 204 리스폰스를 수신했어도 화면이 변하는 일은 없다는 것을 의미합니다.

즉 클라이언트에서 서버에게 정보를 보내는 것만으로도 족하고 클라이언트에 대해서 새로운 정보를 보낼 필요가 없는 경우에 사용됩니다.

206 Partitial Content

이 리스폰스는 Range에 의해 범위가 지정된 리퀘스트에 의해 서버가 부분적 GET리퀘스트를 받았음을 나타냅니다.

리스폰스에는 Content Range로 지정된 범위의 엔티티가 포함됩니다.

범위가 하나만 있는경우 전체 응답의 Content-Type이 document 타입으로 설정되고 Content-Range가 제공됩니다.

여러 범위가 전송되면 Content-Type이 multipart/byterange 로 설정되고 각각의 부분은 Content-Range와 Content-Type으로 묘사되는 하나의 범위로 덮입니다.

ex)

one single range

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

# 26012 bytes of partial image data…

several ranges

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=String_separator

--String_separator
Content-Type: application/pdf
Content-Range: bytes 234-639/8000

# the first range
--String_separator
Content-Type: application/pdf
Content-Range: bytes 4590-7999/8000

# the second range
--String_separator--

 

3xx 리다이렉트(Redirection)

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

301 Moved Permanently

영구 리다이렉션:

발생하는 시기 : 웹사이트가 도메인 이름, URL을 변경할 때

이 리스폰스는 리퀘스트된 리소스에는 새로운 URI가 부여되어 있기 때문에 그 이후로는 그 리소스를 참조하는 새로운 URI를 사용해야한다는 것을 나타내고 있습니다.

301이 발생하는 상황으로는 아래와 같이 디렉토리를 지정할 때 마지막 부분에 슬래시(/)를 붙이는 것을 잊은 경우 등이 있습니다.

301 영구 리다이렉션 예시

• 이전 URL: http://www.example.com/page1.html
• 새 URL: http://www.example.com/page2.html

- 추가 설명 -

301 상태 코드는 페이지가 새 위치로 영구적으로 이동되었음을 나타냅니다. 이는 일반적으로 웹사이트가 도메인 이름이나 URL 구조를 변경하는 경우입니다. 검색 엔진이 사이트를 크롤링하고 301 상태 코드를 발견하면 페이지의 새 위치를 반영하도록 기록을 업데이트합니다.

301 리디렉션은 페이지의 URL이 변경될 때 검색 엔진 순위를 유지하므로 SEO에 중요합니다. 301 리디렉션 없이 페이지가 이동되면 검색 엔진은 해당 이동을 기존 순위가 없는 새 페이지로 해석합니다. 이로 인해 트래픽 수준이 크게 떨어질 수 있습니다.

301 상태 코드를 수정하려면 이전 URL에서 새 URL로의 영구 리디렉션을 설정하기만 하면 됩니다. 서버 구성에 따라 다양한 방법을 사용하여 이 작업을 수행할 수 있습니다.

302 Found

이 리스폰스는 리퀘스트된 리소스에는 새로운 URI가 할당 되어 있으니 그 URI를 참조해주길 바란다는 의미를 나냅니다.

301과 비슷하지만 302의 경우에는 일시적인 것이며 결국 이동하는 곳의 URI는 앞으로 이동 가능성이 있습니다.

302를 사용하면 검색 엔진 크롤러가 리다이렉션을 일시적인 것으로 처리합니다.

303 See Other

이 리스폰스는 리퀘스트에 대한 리소스는 다른 URI에 있기 때문에 GET메소드를 사용해서 얻어야한다는 것을 나타내고 있습니다.

302 Found와 같은 기능이지만 리다이렉트 장소를 GET메소드로 얻어야한다고 명확하게 돼있는 것이 302와의 차이점입니다. 또 303 Redirection은 일시적이고 301 Redirection은 영구적입니다. 그러므로 어떤유형의 리다이렉션을 사용해야할지 모르겠으면 301 Redirection은 주의를 기울여 사용하는 것이 가장 좋습니다.

301, 302, 303 리스폰스 코드가 되돌아오면 대부분의 브라우저에서 POST를 GET으로 변경하여 엔티티 바디를 삭제하고 리퀘스트를 자동적으로 재송신하도록 되어있습니다.

304 Not Modified

이 리스폰스는 클라이언트가 조건부 리퀘스트를 했을 때 리소스에 대한 액세스는 허락하지만 조건이 충족되지 않았음을 표시합니다. 304는 리스폰스 바디에 어떤 것도 포함되어 있어서는 안되고 리다이렉트와는 관계 없습니다.

307 Temporary Redirect

302 Found와 같은 의미를 지니지만 307에서는 브라우저 사양에 따라 POST를 GET으로 치환하지 않습니다. (브라우저마다 리스폰스 처리 동작 다를 수 있음)

 

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

4xx 리스폰스는 클라이언트의 원인으로 에러가 발생했음을 나타냅니다.

400 Bad Request

이 리스폰스는 리퀘스트 구문이 잘못되었음을 나타냅니다.

이 에러가 발생한 경우 리퀘스트 내용을 재검토할 필요가 있습니다. 브라우저는 이를 200 OK와 같은 취급을 합니다.

401 Unauthorized

이 리스폰스는 리퀘스트에 HTTP 인증이 필요하다는 것을 나타내고 있습니다. 또한 이미 한 번 리퀘스트가 이루어진 경우에는 유저 인증에 실패했음을 나타냅니다.

403 Forbidden

이 리스폰스는 리퀘스트된 리소스의 액세스가 거부되었음을 나타냅니다. 이때 서버는 거부의 이유를 분명히 하기 위해 엔티티 바디에 기재해서 유저측에 표시합니다.

401 vs 403

401은 너 누군데? 403은 넌 안돼 라고 생각할 수 있습니다.

예를 들면 401은 로그인이 되지 않았을 때, 403은 로그인은 했지만 권한(관리자)이 없을 때 보내주는 상태코드입니다.

하나 주의해야할 부분은 403(Forbidden)이 발생했다는 것은 “해당 요청에 대한 자원이 존재함”을 내포하기 때문에 리소스의 존재 여부를 알 수 있고 이는 취약점을 찾아서 파고드려는 공격자에게 힌트를 주는 것입니다.

따라서 보안정책에 따라서 권한 없음이 아니라 자원 존재 자체를 숨기고 싶다면 404(Not Found)를 사용하는 것이 하나의 방법이 될 수 있습니다. 대표적으로 Github의 비공개 레포지토리에 접근하는 경우에 404를 띄어줍니다.

따라서 응답상태에 정답이 있기 보다는 상황에 따라 유연하게 가져갈 수 있음을 참고하는 것이 좋습니다

https://mangkyu.tistory.com/146

404 Not Found

이 리스톤스는 리퀘스트한 리소스가 서버상에 없다는 것을 나타냅니다. 그 외에도 서버 측에서 해당 리퀘스트를 거부하고 싶은 이유를 분명히 하고 싶지 않은 경우(예를 들면 보안상)에도 이용할 수 있습니다.

 

5xx 서버 에러 (Server Error)

5xx 리스폰스는 서버 원인으로 에러가 발생하고 있음을 나타냅니다.

500 Internal Server Error

서버에 리퀘스트를 처리하는 도중에 에러가 발생하였음을 나타냅니다.

웹 애플리케이션 에러가 발생한 경우나 일시적인 경우도 있습니다.

503 Service Unavailable

서버가 과부하 상태거나 점검중이기 때문에 현재 리퀘스트를 처리할 수 없음을 나타냅니다.

상태가 해소되기까지 시간이 걸리는 경우에는 Retry-After 헤더필드에 따라 클라이언트에 전달하는 것이 바람직합니다.

Retry-After

Retry-After 유저가 후속 요청을 하기 전에 얼마나 기다려야 하는지를 나타내는 HTTP헤더이다.

다음과 같이 3가지 케이스에 사용되는데

• 503 response를 받을 때 : 서비스 사용불가가 얼마나 걸릴지 나타냄 (서버 사용불가)
• 429 response를 받을 때 : 새로운 리퀘스트를 받기 전에 얼마나 기다려야하는지 나타냄(리퀘스트 너무 많음)
• 301(redirect) response를 받을 때 : 유저가 리다이렉트 요청을 발행하기 전까지 기다려야하는 최소시간을 나타냄

Syntax

Retry-After: <http-date>
Retry-After: <delay-seconds>

http-date : 재시도할 날짜.

delay-seconds : 십진수, response가 수신된 후 딜레이되는 시간