HTTP 상태코드 정리

 

📌 참고
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
- https://www.rfc-editor.org/rfc/rfc2616#page-39
- https://evan-moon.github.io/2020/03/15/about-http-status-code/#500%EB%B2%88%EB%8C%80

분류

서버가 게이트웨이 역할을 하고 있으며 한 서버가 엑세스하고 있는 다른 서버에 적시에 응답을 받지 못했음을 의미한다.

HTTP 응답 상태코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려주며 크게 5개의 그룹으로 나누어진다.

상태코드는 3자리 숫자로, 100번대에서 500번대까지 있다. 주로 200번대와 400번대, 500번대를 보게 된다.

• 1xx (informational response) : 요청을 받았으며 프로세스를 계속 진행한다는 상태코드
• 2xx (Successful response) : 요청을 성공적으로 받았으며(received), 이해했고(understood), 받아들여졌다는 상태코드(accepted)
• 3xx (Redirection messages) : 요청을 완료하기 위해 추가적인 액션이 반드시 수행되어져야 한다는 상태코드
• 4xx (Client error response) : 응답이 잘못된 문법을 포함하고 있거나 수행될 수 없는 요청을 나타내는 상태코드
• 5xx (Server error response) : 명백히 유효한 요청을 서버가 수행할 수 없을 때 반환하는 상태코드

1xx : Information response

이 경우, 서버가 요청을 받았으며 서버에 연결된 클라이언트는 작업을 계속 진행하라는 의미이다. HTTP 1.0에서 지원하지는 않는 상태코드이다.

--> 잘 쓰이지는 않는 것 같다...?

100 Continue

이 응답은 임시적인 응답이며, 클라이언트에게 요청의 시작부분을 받았고 아직 서버에 의해 거절되지는 않았음을 알릴 때 사용한다. 따라서 클라이언트는 반드시 나머지 요청을 계속해야 하며 또는 요청이 이미 완료되었다면 이 응답을 무시해도 된다. 서버는 반드시 최종 응답을 요청이 완료된 후에 보내야만 한다.

2xx : Successful response

200 OK

요청이 성공적으로 되었습니다. 성공의 의미는 HTTP 메소드에 따라 달라집니다.

• GET: 리소스를 불러와서 메시지 바디에 전송되었습니다.
• HEAD: 개체 해더가 메시지 바디에 있습니다.
• PUT 또는 POST: 수행 결과에 대한 리소스가 메시지 바디에 전송되었습니다.
• TRACE: 메시지 바디는 서버에서 수신한 요청 메시지를 포함하고 있습니다.

201 Created

요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었음을 알리는 상태코드. 보통 POST요청 또는 PUT 요청에 대한 응답으로 보낸다. 보통 회원가입과 같은 요청에 대한 응답코드로 많이 썼다.

202 Accepted

202(Accepted) 상태 코드는 요청이 처리를 위해 수락되었지만 처리가 완료되지 않았음을 나타낸다. 요청이 실제로 처리 될 때 허용되지 않을 수 있으므로 요청이 결국 실행되거나 실행되지 않을 수 있다는 뜻이다. HTTP에는 비동기 작업에서 상태 코드를 다시 보내는 기능이 없기 때문에, 의도적으로 모호하게 202 응답을 보내는 것이다.

이러한 상태코드를 사용하는 목적은 서버가 요청에 대한 프로세스가 완료 될 때까지 서버에 대한 사용자 에이전트의 연결이 유지될 필요가 없이, 서버가 다른 프로세스 (아마도 하루에 한 번 실행되는 일괄 처리 지향 프로세스)에 대한 요청을 수락할 수 있도록 허용하기  위해서라고 한다. 이 응답과 함께 전송된 표현은 요청의 현재 상태를 설명하고 요청이 언제 충족될지에 대한 추정치를 사용자에게 제공할 수 있는 상태를 알려주어야 한다.

아직 써보지는 않았다.

203 Non-Autoritative Inforamation

요청은 성공적으로 수행 되었으나, 요청에 대한 검증이 되지 않음을 의미한다.

204 No content

요청이 성공적으로 수행되었고, 응답 payload에 보낼 데이터가 없음을 의미한다. 즉, 요청과 관련된 data가 깔끔히 삭제되었음을 의미한다. 주로 DELETE 요청에 대한 응답으로 사용했다.

3xx : Redirection message

300번대 상태코드는 리다이렉션과 관련되어 있다. 클라이언트가 요청한 리소스가 옮겨졌거나 삭제되어서 다른 url을 통해 해당 리소스에 접근이 가능한 경우 서버가 해당 url을 리다이렉트 가능한 url로 전달해주고자 사용한다.

 

301 Moved Permanetly (Redirect)

브라우저는 자신의 요청에 대한 응답으로 301을 받으면 HTTP헤더에 있는 Location 필드에 있는 URL로 자동 리다이렉션한다.

또한 구글과 같은 검색 엔진의 봇들은 특정 페이지에 접근했는데 응답으로 301 상태 코드를 받을 경우 자동으로 페이지 정보를 갱신하기도 하기 때문에, SEO(Search Engine Optimization) 관점에서도 이 상태 코드를 올바르게 사용하는 것은 매우 중요하다.

이런 리다이렉션 설정은 보통 서버 엔진의 설정 파일 내에서도 할 수 있고, 백엔드 어플리케이션 내에서 직접 할 수도 있다. 일반적인 경우 이 상태코드는 HTTP 프로토콜로 접속한 사용자를 HTTPS 프로토콜을 사용해야만 접근 가능한 포트로 보내버릴 때에도 많이 사용된다.

server {
    listen         80;
    server_name    evan.com;
    return         301 https://$host$request_uri;
}

server {
    listen         443 ssl;
    server_name    evan.com;
    ...
}

이 경우 80 포트로 접속한 사용자를 발견한 Nginx는 HTTPS 프로토콜을 사용해야만 접근할 수 있는 443 포트로 리다이렉트시켜서 해당 프로토콜 사용을 강제할 수 있다.

304 Not Modified

리소스가 수정되지 않음을 의미합니다. 즉, 클라이언트가 요청한 리소스가 이전 요청때와 비교했을 때, 전혀 달라진 점이 없다는 것을 의미한다. 따라서, 해당 응답을 받으면, 클라이언트는 서버로부터 리소스를 재전송 받지 않고, 캐싱된 리소스를 사용한다. 즉, 클라이언트는 서버로부터 요청된 리소스를 받은 것이 아니라 자신이 캐싱해놓았던 리소스를 사용하는 것이므로 이 또한 캐싱된 리소스로 리다이렉션되었다고 생각하는 것이다.

4xx : Client error

400 Bad Request

잘못된 문법 등으로 인해 클라이언트가 올바르지 못한 요청을 보내 서버가 이행할 수 없음을 나타내는 상태코드

401 Unauthorized

인증되지 않은 사용자가 인증이 필요한 리소스를 요청하는 경우의 상태코드. 보통 인증이 필요한 리소스를 사용자가 요청하는 경우에 사용된다. 그래서, 클라이언트에서는 401을 받으면 로그인 페이지로 리다이렉션 하기도 한다고 한다.

403 Forbidden

클라이언트가 콘텐츠에 접근할 권한이 없음을 나타낸다 403의 경우, 백엔드 어플리케이션은 현재 리소스를 요청한 사용자가 누구인지 전혀 신경쓰지 않는다. 클라이언트가 현재 자신이 누구인지 밝혔던 밝히지 않았던, 인증이 되었던 안 되었던 간에, 이 리소스를 요청하는 것은 무조건 금지라고 말하고 있는 것이다.

HTTPS 프로토콜로만 접근해야하는 리소스에 HTTP 프로토콜을 사용하여 접근했을 경우에 서버에서 403 응답을 보내주기도 한다. 보통 차단되어 있는 사이트에 접속을 시도한 경우 사용된다.

 

404 Not Found

요청한 리소스가 존재하지 않음을 의미합니다. 인증되지 않은 클라이언트로부터 리소스를 숨기기 위해 403 대신 이 응답을 전송하기도 합니다. 주로 찾고자 하는 리소스가 없거가 요청한 API Route가 존재하지 않을 때 사용.

405 Method Not Allowed

현재 리소스에 맞지 않는 메서드를 사용했음을 의미합니다. 예로는 GET 요청만 허용되는데 POST 요청을 한 경우의 응답입니다.

406 No Acceptable

알맞은 콘텐츠 타입이 없음을 의미한다. 서버의 리소스가 클라이언트의 HTTP헤더에 들어있는 Accept 필드에 명시된 콘텐츠 타입이 아닌 경우의 응답.

408 Request Timeout

요청에 응답하는 시간이 너무 오래걸림을 의미한다.

409 Conflict

요청이 현재 서버 상태와 충돌될 때의 응답. 이미 회원가입 된 유저에 대해 다시 회원가입을 시도할 때, 좋아요 처리가 된 것에 대해 다시 좋아요 요청을 할 때 등의 상황에서 사용된다.

410 Gone

이 응답은 요청한 콘텐츠가 서버에서 영구적으로 삭제되었으며, 전달해 줄 수 있는 주소 역시 존재하지 않을 때 보냅니다. 따라서 클라이언트가 그들의 캐쉬와 리소스에 대한 링크를 지우기를 기대한다. 그래서 일시적이거나 홍보용 서비스처럼 기간 만료가 정해져 있을 때 기간 만료 후 사용하곤 한다.

413 Payload too large

요청이 너무 커서 서버가 처리할 수 없을 때의 응답이다. 파일 등을 전달 받을 때 파일의 크기가 정의한 값보다 큰 경우와 같은 상황에 사용한다.

429 Too many requests

클라이언트가 지정되 시간에 너무 많은 요청을 보낸 경우의 응답이다.

5xx : Server error

500 Internal Server Error

서버에 오류가 발생하여 응답할 수 없음을 의미한다. 서버에 오류가 발생했으나 처리 방법을 알 수 없을 때 사용한다. 즉, 예외처리되지 않은 오류에 대해서 처리할 때 이 상태코드를 사용한다. DB에 오류가 있거나 예외처리 안된 오류가 발생했을 때 이 코드가 응답된다.

또한 이렇게 핸들링되지 않은 에러의 원인을 클라이언트에게 고스란히 알려주는 것은 보안 사고가 발생할 가능성이 너무 크므로, 500 상태 코드로 에러의 발생 자체만을 알려주는 경우가 대부분이다. 만약 이 상태 코드를 만난다면, 바로 서버 로그를 까보거나 Sentry나 Bugsnag과 같은 에러 모니터링 솔루션을 적극 활용하는 것을 추천한다.

501 Not Implemented

클라이언트 요청에 대한 서버의 응답 수행 기능이 없었음을 의미합니다.

502 Bad Gateway

서버가 게이트웨이로부터 잘못된 응답을 수신했음을 의미한다. 서버의 부모 서버에서 오류가 발생한 경우의 응답이다. 보통 서버가 접속하는 사용자가 많아 과부하될 때 발생한다.

 

상태 코드 502를 만날 수 있는 가장 흔한 상황은 바로 백엔드 어플리케이션이 죽은 상황이다. 근데 왜 Server Died와 같이 직접적인 메세지가 아니라 Bad Gateway와 같은 메세지를 보내주는 것일까?

그 이유는 백엔드 아키텍처가 아무리 간단한 구조라고 해도 절대 어플리케이션 1개로만 구성되지 않기 때문이다. 여기서 말하는 게이트웨이는 어플리케이션 간의 추상적인 연결점을 의미하는데, 이 메세지가 의미하듯 백엔드의 아키텍처는 최소 2개 이상의 어플리케이션으로 구성된 경우가 대부분이다.

일반적인 경우 클라이언트가 보낸 요청은 곧바로 백엔드 어플리케이션에 전달되는 것이 아니다. 사실 백엔드 어플리케이션에 앞단에는 아파치나 Nginx 같은 서버 엔진이나 로드밸런서 같은 친구들이 대신 요청을 받아서 백엔드 어플리케이션으로 전달해주는 경우가 대부분이다.

server {
    listen 80;

    server_name evan.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

 

Nginx를 사용하면 일반적으로 이런 설정을 사용하게 되는데, 이렇게 되면 Nginx는 80번 포트에서 대기하며 HTTP 프로토콜을 사용한 요청을 받아 3000번 포트에서 대기하고 있는 백엔드 어플리케이션에게 전달해주는 역할을 수행하게 된다.

이런 아키텍처를 사용하는 이유는 보안과 처리 효율 때문이다. 백엔드 어플리케이션 자체가 완전무결한 친구가 아니기 때문에 모든 요청을 안심하고 백엔드 어플리케이션에게 먹여줄 수가 없는 것이다. 그렇다고 누가 사용하는 지도 모르는 클라이언트에서 안전한 요청만 보내줄 것이라는 기대 또한 어불성설이다.

게다가 뭔가 연산이 필요한 요청이 아닌, 파일을 찾아서 보내주기만 하는 간단한 요청 같은 경우는 굳이 안 그래도 바쁜 백엔드 어플리케이션에게 시킬 필요가 없으므로 이런 서버 엔진이 대신 처리해주기도 한다.

그래서 백엔드에서는 앞 단에 아예 프록시 서버를 두어서 문지기 역할을 시키는 것이다. 이때 이 프록시 서버와 백엔드 어플리케이션 간의 연결된 추상적인 통로를 “게이트웨이”라고 부르는 것이다. 백엔드 어플리케이션이 죽어버릴 경우 앞 단의 문지기인 프록시 서버는 백엔드 어플리케이션에게 아무런 응답을 받지 못하게 되고, 클라이언트에게 502 Bad Gateway라는 응답을 보내주는 것이다.

503 Services unavailable

 상태 코드 503은 서버가 요청을 처리할 준비가 되지 않았음을 의미한다. 간혹 502 Bad Gateway와 비슷한 느낌으로 사용되기는 하지만, 503은 보다 “일시적인 상황”을 의미하는 상태 코드이며, 일반적으로 서버에 부하가 심해서 현재 요청을 핸들링 할 수 있는 여유가 없는 경우에 많이 사용된다.

AWS Lambda에서는 요청을 처리할 때 컨테이너의 동시 실행 갯수를 초과할 정도의 리소스가 필요하거나 어떤 작업의 처리 시간이 Lambda에 설정된 컨테이너의 최대 수명 시간을 초과했을 경우에 발생하기도 한다.

이렇듯이 503은 일시적인 상황을 의미하므로 429 Too Many Requests와 동일하게 응답 헤더의 Retry-After 필드를 사용하여 “이 시간 이후에 다시 요청해봐”라는 의미를 클라이언트에게 전달해줄 수 있다.

 

504 Gateway Timeout

상태 코드 504는 408과 마찬가지로 요청에 대한 타임아웃을 의미한다. 그러나 504 상태 코드는 클라이언트에서 보낸 요청 때문에 타임아웃이 발생하는 것이 아니라 백엔드 아키텍처 내부에서 서버끼리 주고받는 요청에서 발생한다.

앞서 이야기했듯이 백엔드의 아키텍처는 단순히 백엔드 어플리케이션 하나로만 구성된 것이 아니기 때문에, 클라이언트의 요청이 서버에 닿은 뒤에도 백엔드 어플리케이션끼리의 통신이 발생하게 된다. 만약 프록시 서버 역할을 맡은 Nginx가 백엔드 어플리케이션에 클라이언트의 요청을 전달했는데, 백엔드 어플리케이션이 일정 시간 동안 응답을 하지 않는 경우 Nginx는 클라이언트에게 504 Geteway Timeout을 내려주게 되는 것이다.