티스토리 뷰
📌 HTTP 클라이언트 에러 응답
웹 개발에서 HTTP 4xx 상태 코드는 클라이언트 오류를 나타내는 중요한 신호입니다.
이러한 오류는 주로 클라이언트 요청에 문제가 있을 때 발생하며, 개발자가 이를 이해하고 적절히 처리하는 방법을
아는 것은 사용자 경험을 개선하는 데 매우 중요합니다.
📌 기본 정의
HTTP 4xx 상태 코드는 클라이언트가 서버에 보낸 요청에 문제가 있을 때 서버가 반환하는 코드입니다.
이러한 코드는 클라이언트가 요청을 수정하여 다시 시도해야 함을 나타냅니다.
4xx 코드는 클라이언트 측 문제로 인해 발생하며, 잘못된 요청 문법, 인증 오류, 권한 문제, 찾을 수 없는 자원 등
다양한 원인으로 인해 발생할 수 있습니다.
- 클라이언트 측 문제: 4xx 코드는 서버가 아닌 클라이언트 측에서 문제를 해결해야 함을 나타냅니다.
- 사용자 조치 필요: 사용자는 요청을 수정하거나 다른 URL로 요청을 보내는 등의 조치를 취해야 할 수 있습니다.
- 다양한 시나리오: 4xx 오류는 잘못된 입력, 인증 실패, 권한 부족 등 다양한 상황에서 발생할 수 있습니다.
📌 코드 정의
✔️ 400 Bad Request
이 응답은 잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미합니다.
예시:
GET /example.com/% HTTP/1.1
Host: example.com서버 응답:
HTTP/1.1 400 Bad Request
✔️ 401 Unauthorized
인증이 필요한 리소스에 대해 클라이언트가 유효한 인증 정보를 제공하지 않은(unauthorized) 경우 발생합니다.
이 코드가 나타나면 클라이언트는 인증 자격 증명을 포함하여 요청을 다시 시도해야 합니다.
✔️ 402 Payment Required
이 응답 코드는 나중에 사용될 것을 대비해 예약되었습니다.
첫 목표로는 디지털 결제 시스템에 사용하기 위하여 만들어졌지만 지금 사용되고 있지는 않습니다.
✔️ 403 Forbidden
클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않습니다.
예를들어 그들은 미승인이어서 서버는 거절을 위한 적절한 응답을 보냅니다.
401과 다른 점은 서버가 클라이언트가 누구인지 알고 있습니다.
예시:
GET /restricted-area HTTP/1.1
Host: example.com
Authorization: Basic YWRtaW46cGFzc3dvcmQ=서버 응답:
HTTP/1.1 403 Forbidden
✔️ 404 Not Found
서버는 요청받은 리소스를 찾을 수 없습니다. 브라우저에서는 알려지지 않은 URL을 의미합니다.
이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있습니다.
서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있습니다.
이 응답 코드는 웹에서 반복적으로 발생하기 때문에 가장 유명할지도 모릅니다.
✔️ 405 Method Not Allowed
요청한 메소드는 서버에서 알고 있지만, 제거되었고 사용할 수 없습니다.
예를 들어, 어떤 API에서 리소스를 삭제하는 것을 금지할 수 있습니다.
필수적인 메소드인 GET과 HEAD는 제거될 수 없으며 이 에러 코드를 리턴할 수 없습니다.
✔️ 406 Not Acceptable
이 응답은 서버가 서버 주도 콘텐츠 협상 을 수행한 이후, 사용자 에이전트에서 정해준 규격에 따른 어떠한 콘텐츠도
찾지 않았을 때, 웹서버가 보냅니다.
✔️ 407 Proxy Authentication Required
이것은 401과 비슷하지만 프록시에 의해 완료된 인증이 필요합니다.
✔️ 408 Request Timeout
이 응답은 요청을 한지 시간이 오래된 연결에 일부 서버가 전송하며, 어떨 때에는 이전에 클라이언트로부터 어떠한
요청이 없었다고 하더라도 보내지기도 합니다.
이것은 서버가 사용되지 않는 연결을 끊고 싶어한다는 것을 의미합니다.
이 응답은 특정 몇몇 브라우저에서 빈번하게 보이는데, Chrome, Firefox 27+, 또는 IE9와 같은 웹서핑 속도를
올리기 위해 HTTP 사전 연결 메카니즘을 사용하는 브라우저들이 해당됩니다.
또한 일부 서버는 이 메시지를 보내지 않고 연결을 끊어버리기도 합니다.
✔️ 409 Conflict
이 응답은 요청이 현재 서버의 상태와 충돌될 때 보냅니다.
✔️ 410 Gone
이 응답은 요청한 콘텐츠가 서버에서 영구적으로 삭제되었으며, 전달해 줄 수 있는 주소 역시 존재하지 않을 때
보냅니다. 클라이언트가 그들의 캐쉬와 리소스에 대한 링크를 지우기를 기대합니다.
HTTP 기술 사양은 이 상태 코드가 "일시적인, 홍보용 서비스"에 사용되기를 기대합니다. API는 알려진 리소스가
이 상태 코드와 함께 삭제되었다고 강요해서는 안된다.
✔️ 411 Length Required
서버에서 필요로 하는 Content-Length 헤더 필드가 정의되지 않은 요청이 들어왔기 때문에 서버가 요청을
거절합니다.
✔️ 412 Precondition Failed
클라이언트의 헤더에 있는 전제조건은 서버의 전제조건에 적절하지 않습니다.
✔️ 413 Payload Too Large
요청 엔티티는 서버에서 정의한 한계보다 큽니다.
서버는 연결을 끊거나 혹은 Retry-After 헤더 필드로 돌려보낼 것이다.
✔️ 414 URI Too Long
클라이언트가 요청한 URI는 서버에서 처리하지 않기로 한 길이보다 깁니다.
✔️ 415 Unsupported Media Type
요청한 미디어 포맷은 서버에서 지원하지 않습니다, 서버는 해당 요청을 거절할 것입니다.
✔️ 416 Requested Range Not Satisfiable
Range 헤더 필드에 요청한 지정 범위를 만족시킬 수 없습니다; 범위가 타겟 URI 데이터의 크기를 벗어났을 가능성이 있습니다.
✔️ 417 Expectation Failed
이 응답 코드는 Expect 요청 헤더 필드로 요청한 예상이 서버에서는 적당하지 않음을 알려줍니다.
✔️ 418 I'm a teapot
서버는 커피를 찻 주전자에 끓이는 것을 거절합니다.
✔️ 421 Misdirected Request
서버로 유도된 요청은 응답을 생성할 수 없습니다. 이것은 서버에서 요청 URI와 연결된 스킴과 권한을 구성하여 응답을 생성할 수 없을 때 보내집니다.
✔️ 422 Unprocessable Entity (WebDAV)
요청은 잘 만들어졌지만, 문법 오류로 인하여 따를 수 없습니다.
✔️ 423 Locked (WebDAV)
리소스는 접근하는 것이 잠겨있습니다.
✔️ 424 Failed Dependency (WebDAV)
이전 요청이 실패하였기 때문에 지금의 요청도 실패하였습니다.
✔️ 426 Upgrade Required
서버는 지금의 프로토콜을 사용하여 요청을 처리하는 것을 거절하였지만, 클라이언트가 다른 프로토콜로 업그레이드를 하면 처리를 할지도 모릅니다. 서버는 Upgrade 헤더와 필요로 하는 프로토콜을 알려주기 위해 426 응답에 보냅니다.
✔️ 428 Precondition Required
오리진 서버는 요청이 조건적이어야 합니다. 클라이언트가 리소스를 GET해서, 수정하고, 그리고 PUT으로 서버에 돌려놓는 동안 서드파티가 서버의 상태를 수정하여 발생하는 충돌인 '업데이트 상실'을 예방하기 위한 목적입니다.
✔️ 429 Too Many Requests
사용자가 지정된 시간에 너무 많은 요청을 보냈습니다("rate limiting").
✔️ 431 Request Header Fields Too Large
요청한 헤더 필드가 너무 크기 때문에 서버는 요청을 처리하지 않을 것입니다. 요청은 크기를 줄인 다음에 다시 전송해야 합니다.
✔️ 451 Unavailable For Legal Reasons
사용자가 요청한 것은 정부에 의해 검열된 웹 페이지와 같은 불법적인 리소스입니다.
📌 HTTP 4xx 상태 코드의 일반적인 처리 방법
1. 클라이언트 측 유효성 검사
4xx 오류를 방지하려면, 클라이언트 측에서 유효성 검사를 통해 잘못된 요청이 서버로 전송되지 않도록 해야 합니다. 입력 데이터, URL 형식, 요청 헤더 등을 미리 점검하는 것이 중요합니다.
2. 오류 처리 및 사용자 피드백
애플리케이션에서 4xx 오류가 발생했을 때, 사용자에게 명확한 피드백을 제공해야 합니다.
예를 들어, "잘못된 입력입니다. 다시 시도해 주세요."와 같은 메시지를 통해 사용자가 오류를 이해하고
수정할 수 있도록 도와야 합니다.
3. 리소스 경로의 정확성 유지
404 오류를 방지하려면 리소스 경로와 링크를 정확하게 유지하는 것이 중요합니다.
정기적으로 사이트를 검토하여 깨진 링크를 수정하고, 리소스가 이동되거나 삭제되었을 때 적절한 리디렉션을
설정해야 합니다.
4. 서버 로그 분석
서버 로그를 정기적으로 분석하여 자주 발생하는 4xx 오류를 모니터링하세요.
이는 사용자가 자주 실수하는 부분을 파악하고, UI 개선 또는 사용자 교육을 통해 문제를 해결하는 데 도움이 됩니다.
HTTP 4xx 상태 코드는 단순한 오류 그 이상으로, 애플리케이션의 안정성과 신뢰성을 높이기 위한 중요한 기회를
제공합니다. 이를 잘 관리함으로써 클라이언트와 서버 간의 원활한 상호작용을 보장하고,
웹 애플리케이션의 전체적인 품질을 높일 수 있습니다.