이 글을 작성하는 이유
400, 401, 402, 403, 404는 자주 만나봤는데 가끔 마주치는 에러 코드에 대해 바로 떠오르지 않는 경우가 있는데, 이번에 HTTP response status code에 대해 한번 정리해본다.
HTTP 응답 상태 코드
클라이언트가 서버로 보낸 요청에 문제가 없으니 다음 요청을 보내라는 뜻이고, 다음 요청할 게 없으면 무시하면 된다.
이를 수행하게 하려면 클라이언트는 첫 요청에서 Expect :100-continue를 헤더로 보낸다.
예제
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
JSON
복사
deprecated
•
200 응답은 요청 성공을 의미하며, 기본적으로 캐시 가능하다.
성공의 의미는 아래와 같이 HTTP 요청 메서드에 따라 나뉜다.
•
GET: 리소스가 검색되어 메시지 본문으로 전송
•
HEAD: 메시지 본문 없이 표현 헤더가 응답에 포함
•
POST: 행동의 결과를 설명하는 리소스가 메시지 본문으로 전송
•
TRACE: 메시지 본문에는 서버에서 수신한 요청 메시지가 포함
•
PUT 또는 DELETE의 성공적인 결과는 종종 200 OK가 아니라 204 No Content (또는 리소스가 처음 업로드되는 경우 201 Created)
HTTP 성공 상태 응답 코드 201 Created는 요청이 성공하고 새로운 리소스가 생성되었음을 나타낸다.
새로운 리소스 또는 새로운 리소스에 대한 설명과 링크는 응답이 반환되기 전에 효과적으로 생성되며, 새로 생성된 항목은 요청 URL이나 Location 헤더 값의 URL에 위치한 메시지 본문의 반환값으로 반환된다.
이 상태 코드의 일반적인 사용 사례는 POST 요청의 결과로 사용된다.
HTTP 202 Accepted 응답 상태 코드는 요청이 처리를 위해 수락되었지만, 처리가 완료되지 않았음을 나타낸다.
사실 처리가 아직 시작되지 않았을 수도 있다. 요청은 처리될 수도 있고 아닐 수도 있으며, 처리가 실제로 진행될 때 처리가 금지될 수도 있다.
202는 "약속이 없다". HTTP가 나중에 요청 처리 결과를 알려주기 위한 표준화된 방법이 없다는 것을 의미한다.
즉, HTTP 202 Accepted 상태 코드는 요청이 성공적으로 처리되었으며, 결과를 나중에 알려줄 수 있다는 것을 의미하지만, 이후 처리 결과를 전달하기 위한 표준화된 방법이 없다는 것이다.
따라서, 이러한 경우 요청을 처리하는 다른 프로세스나 서버에서 처리 결과를 추적하고 필요에 따라 알림을 보내는 등의 방법을 사용해야 한다.
HTTP 203 Non-Authoritative Information 응답 상태 코드는 요청이 성공적이었지만, transforming proxy에 의해 원 서버의 200(OK) 응답과는 다른 페이로드로 수정되었음을 나타낸다.
203 응답은 Warning 헤더 코드의 값 중 Transformation Applied (214)과 유사하며, 모든 상태 코드의 응답에 적용 가능한 추가적인 이점이 있다.
라고 MDN에는 적혀 있는데, 203을 transforming proxy에서 다른 페이로드로 수정했음을 왜 나타내야 할까? 언제 사용해야 할까?
203 상태 코드는 주로 프록시 서버에서 캐시된 응답을 변환하여 제공할 때 사용됩니다. 예를 들어, 원래 서버에서 반환된 응답을 프록시 서버에서 필터링하여 일부 컨텐츠를 수정한 경우 203 상태 코드를 반환하여 클라이언트가 수정된 응답임을 인식하도록 합니다.
이렇게 변환된 응답은 "Non-Authoritative Information"으로 표시됩니다. 즉, 원 서버에서 직접 반환된 것이 아니라 프록시 서버에서 수정된 것임을 나타내며, 클라이언트가 캐시된 응답이 아니라 원래 서버에서 받은 응답과 다르다는 것을 인식할 수 있습니다.
HTTP 204 No Content 성공 상태 응답 코드는 요청이 성공했지만, 클라이언트가 현재 페이지를 벗어나지 않아도 되는 것을 나타낸다.
예를 들어 위키 사이트의 "저장 및 편집 계속" 기능을 구현할 때 사용될 수 있다. 이 경우 PUT 요청이 사용되어 페이지를 저장하고, 204 No Content 응답이 보내져 편집기가 다른 페이지로 대체되지 않아야 함을 나타낸다.
HTTP 205 Reset Content 응답 상태는 클라이언트에게 document view를 재설정하도록 지시하여, 예를 들어 양식의 내용을 지우거나 캔버스 상태를 재설정하거나 UI를 새로 고칠 수 있도록 한다.
여러 범위가 반환되는 경우, Content-Type은 multipart/byteranges로 설정되고 각 조각은 하나의 범위를 포함하며, Content-Range와 Content-Type로 설명된다.
Partial Content는 어디에 쓸까? 잘라서 보내야만 하는 큰 컨텐츠가 있는 경우일 것이다.
HTTP 206 Partial Content는 일반적으로 클라이언트가 서버에서 큰 파일을 다운로드할 때 사용된다. 클라이언트가 전체 파일을 한 번에 다운로드하지 않고, 요청한 범위만큼 파일을 분할해서 다운로드할 수 있습니다. 예를 들어, 사용자가 100MB의 동영상 파일을 다운로드하려고 할 때, 이를 10MB의 10개 조각으로 분할하여 다운로드할 수 있습니다. 클라이언트는 이러한 분할된 범위를 Range 헤더에 지정하고, 서버는 206 Partial Content 응답 코드를 반환하여 클라이언트에게 요청한 범위의 데이터를 제공합니다. 이 방식을 사용하면 다운로드 시간을 줄이고 대역폭을 절약할 수 있습니다.
참고: 리소스 컬렉션을 반환하는 기능은 WebDAV 프로토콜의 일부입니다(웹DAV 서버에 액세스하는 웹 애플리케이션에서 받을 수 있습니다). 웹 페이지에 액세스하는 브라우저는 이 상태 코드를 결코 만나지 않습니다.
HTTP 207 Multi-Status 응답 코드는 응답이 혼합될 수 있음을 나타냅니다.
응답 본문은 multistatus 루트 요소를 가진 text/xml 또는 application/xml HTTP 개체입니다. XML 본문은 모든 개별 응답 코드를 나열합니다.
참고: 여러 경로에 리소스를 바인드하는 능력은 WebDAV 프로토콜의 확장 기능입니다(웹DAV 서버에 액세스하는 웹 애플리케이션에서 수신 가능합니다). 웹 페이지에 액세스하는 브라우저는 이 상태 코드를 결코 만나지 않습니다.
HTTP 208 Already Reported 응답 코드는 공간을 절약하고 충돌을 방지하기 위해 [207](207 Multi-Status) 응답에서 사용됩니다. 동일한 리소스가 다른 경로로 여러 번 요청되는 경우(예: 컬렉션의 일부로), 첫 번째 요청만 [200]으로 보고됩니다. 모든 다른 바인딩에 대한 응답은 이 208 상태 코드로 보고되므로 충돌이 발생하지 않고 응답이 더 짧아집니다.
참고: 브라우저는 HTTP에서 델타 인코딩을 지원하지 않습니다. 이 상태 코드는 특정 클라이언트에서 사용하는 사용자 지정 서버에 의해 반환됩니다.
델타 인코딩의 문맥에서, HTTP 226 IM Used 상태 코드는 서버가 받은 GET 요청에 대해 델타를 반환한다는 것을 나타내기 위해 서버에 의해 설정됩니다.
델타 인코딩에서 서버는 기존 문서가 아닌 주어진 기본 문서에 상대적인 차이 (델타)를 사용하여 GET 요청에 응답합니다. 클라이언트는 A-IM: HTTP 헤더를 사용하여 사용할 차이 알고리즘을 나타내고 If-None-Match: 헤더를 사용하여 마지막으로 받은 버전에 대한 힌트를 제공합니다. 서버는 델타를 생성하여 IM:(사용된 알고리즘의 이름) 및 Delta-Base:(델타에 연결된 기본 문서와 일치하는 ETag를 가진 헤더) HTTP 헤더가 포함된 HTTP 응답으로 반환합니다.
IM은 인스턴스 조작을 나타내며, 델타를 생성하는 알고리즘을 설명하는 용어입니다.
HTTP 300 다중 선택 리디렉션 상태 응답 코드는 요청에 대해 여러 가지 가능한 응답이 있다는 것을 나타낸다. 사용자 에이전트 또는 사용자는 그 중 하나를 선택해야 한다. 응답 중 하나를 선택하는 표준화된 방법이 없기 때문에 이 응답 코드는 매우 드물게 사용된다.
서버가 선호하는 선택이 있는 경우 [Location]헤더를 생성해야 한다.
HyperText 전송 프로토콜(HTTP)의 301 Moved Permanently 리디렉션 상태 응답 코드는 요청한 리소스가 [Location] 헤더에서 주어진 URL로 확실히 이동되었음을 나타낸다.
브라우저는 새 URL로 리디렉션하고 검색 엔진은 리소스에 대한 링크를 업데이트합니다.
참고: 명세서에서는 리디렉션이 수행될 때 Method과 Body를 변경하지 않도록 요구하지만, 모든 사용자 에이전트가이 요구 사항을 충족하지는 않습니다. 301 코드는 [GET] 또는 [HEAD] 방법에 대한 응답으로만 사용하고, 이 상태에서는 방법 변경이 명시적으로 금지되므로 [POST] 방법에 대해서는 [308 영구 리디렉션]을 사용하세요.
위와 같은 이유로 Next.js 에서는 301 영구 리디렉션 대신 308 영구 리디렉션을 사용한다.
하이퍼텍스트 전송 프로토콜(HTTP) 302 Found 리디렉션 상태 응답 코드는 요청한 리소스가 임시로 Location 헤더에서 주어진 URL로 이동되었음을 나타낸다. 브라우저는 이 페이지로 리디렉션하지만 검색 엔진은 리소스에 대한 링크를 업데이트하지 않는다. ('SEO 용어'로는 '링크-주스(link-juice)'가 새 URL로 전송되지 않았다고 한다.)
명세서가 리디렉션 수행시 메서드(및 본문)가 변경되지 않아야 한다고 요구하지만, 모든 사용자 에이전트가 여기에 따르지는 않습니다. 여전히 이러한 종류의 버그가 있는 소프트웨어를 찾을 수 있습니다. 따라서 응답으로 [GET] 또는 [HEAD] 방법을 사용하도록 302 코드를 설정하는 것이 좋습니다. 이 경우 방법 변경이 명시적으로 금지되므로 [307 Temporary Redirect]를 대신 사용하십시오.
위와 같은 이유로 Next.js 에서는 302 임시 리디렉션 대신 307 임시 리디렉션을 사용한다.
[GET]로 변경하려는 경우 [303 See Other]를 사용하세요. 이것은 업로드된 리소스가 아닌 'XYZ를 성공적으로 업로드했습니다'와 같은 확인 메시지를 제공하려는 [PUT] 방법에 대한 응답에 유용하다.
하이퍼텍스트 전송 프로토콜(HTTP) 303 See Other 리디렉션 상태 응답 코드는 리디렉션이 요청된 리소스 자체로 연결되지 않고 다른 페이지(확인 페이지, 실제 세계 객체의 표현 - HTTP range-14 참조, 업로드 진행 페이지 등)로 연결됨을 나타낸다.
이 응답 코드는 종종 [PUT] 또는 [POST] 결과로 보내집니다. 이 리디렉션된 페이지를 표시하는 데 사용된 방법은 항상 [GET]입니다.
HTTP 304 Not Modified 클라이언트 리디렉션 응답 코드는 요청한 리소스를 재전송할 필요가 없음을 나타낸다. 이는 캐시된 리소스로의 암시적인 리디렉션입니다.
이는 요청 방법이 안전한 방법인 GET 또는 HEAD와 같은 경우 또는 요청이 조건부이며 If-None-Match 또는 If-Modified-Since 헤더를 사용하는 경우 발생합니다.
동등한 200 OK 응답은 Cache-Control, Content-Location, Date, ETag, Expires 및 Vary 헤더를 포함했을 것입니다.
HTTP 307 임시 리디렉션(redirect) 상태 응답 코드는 요청한 리소스가 Location 헤더에서 주어진 URL로 일시적으로 이동되었음을 나타낸다.
원래 요청의 Method와 Body는 리디렉트된 요청을 수행하는 데 재사용됩니다. 방법을 GET으로 변경하려는 경우 303 See Other를 대신 사용한다. 이는 업로드된 리소스가 아닌 확인 메시지(예: "XYZ가 성공적으로 업로드되었습니다")를 PUT 방법에 대한 응답으로 제공하려는 경우 유용하다.
307과 302의 유일한 차이점은 307이 리디렉트된 요청을 수행할 때 방법과 본문이 변경되지 않음을 보장한다는 것이다. 302에서는 일부 오래된 클라이언트가 방법을 GET으로 잘못 변경하는 경우가 있어서, 비-GET 방법과 302의 동작은 웹에서 예측할 수 없다. 반면 307의 동작은 예측 가능하다. GET 요청의 경우, 그들의 동작은 동일하다.
HTTP (하이퍼텍스트 전송 프로토콜)의 308 영구 리디렉션 리디렉션 상태 응답 코드는 요청된 리소스가 [Location] 헤더에서 제공된 URL로 확실히 이동되었음을 나타낸다. 브라우저는 이 페이지로 리디렉션하고 검색 엔진은 리소스에 대한 링크를 업데이트한다 ('SEO 용어'로는 '링크 주스'가 새 URL로 전송되었다고 말한다).
요청 메서드와 본문은 변경되지 않지만 [301] 은 때로는 부적절하게 [GET] 메서드로 변경될 수 있다.
참고: 일부 웹 애플리케이션은 308 영구 리디렉션을 비표준 방식으로 사용하며 다른 목적으로 사용할 수 있습니다. 예를 들어 Google Drive는 불완전한 업로드가 중단되었을 때 클라이언트에게 알리기 위해 308 Resume Incomplete 응답을 사용합니다. (Google Drive 문서의 Perform a resumable download 을 참조하세요.)
하이퍼텍스트 전송 프로토콜(HTTP)에서 400 Bad Request 응답 상태 코드는 잘못된 요청 구문, 잘못된 요청 메시지 프레임, 속임수적인 요청 라우팅 등 클라이언트 오류로 인해 서버가 요청을 처리하지 못하거나 처리하지 않을 것으로 인식하는 것을 나타낸다.
경고: 클라이언트는 이 요청을 수정하지 않고 다시 시도해서는 안 됩니다.
하이퍼텍스트 전송 프로토콜(HTTP) 401 Unauthorized 응답 상태 코드는 요청된 리소스에 대한 유효한 인증 자격증명이 없기 때문에 클라이언트 요청이 완료되지 않았음을 나타낸다.
이 상태 코드는 HTTP [WWW-Authenticate] 응답 헤더와 함께 전송되며, 이 헤더에는 사용자가 인증 자격 증명을 입력한 후 리소스를 다시 요청할 수 있는 방법에 대한 정보가 포함되어 있다.
이 상태 코드는 [403 Forbidden](<https://developer.mozilla.org/ko/docs/Web/HTTP/Status/403>) 상태 코드와 유사하지만, 이 상태 코드가 발생하는 상황에서 사용자 인증을 통해 리소스에 액세스할 수 있다.
