##본 포스팅은 '그림으로 배우는 Http & Network Basic - 우에노 센'을 읽고 쓴 요약/정리 글입니다.
상태 코드
클라이언트가 서버를 향해 리퀘스트를 보낼 때 서버에서 그 결과가 어떻게 되었는지 알려주는 것이 상태 코드의 역할이다.
서버가 리퀘스트를 정상적으로 처리했는지, 그렇지 않으면 리퀘스트 결과가 에러였는지를 알 수 있다.
숫자의 첫번째 자리는 리스폰스의 클래스를 의미하는데, 나머지 2자리는 의미가 없다.
상태 코드 앞자리 | 클래스 | 설명 |
1xx | Informational | 리퀘스트를 받아들여 처리 중 |
2xx | Success | 리퀘스트를 정상적으로 처리함 |
3xx | Redirection | 리퀘스트를 완료하기 위해서 추가 동작이 필요 |
4xx | Client Error | 서버가 리퀘스트 이해 불가능 |
5xx | Server Error | 서버가 리퀘스트 처리 실패 |
HTTP 상태 코드는 60종류 이상이 있지만, 실제로 자주 사용되고 있는 것은 14종류 정도
2xx 성공(Success)
정상적인 처리를 의미
<200 OK>
상태코드와 되돌아 오는 정보 : 메소드에 따라 다름
-> GET : 리퀘스트된 리소스에 대응하는 엔티티
-> HEAD : 리퀘스트된 리소스에 대응하는 엔티티 헤더 필드가 메시지 바디를 동반하지 않고
<204 No Content>
리퀘스트를 받아서 처리하는 데는 성공했지만 리스폰스에 엔티티 바디를 포함하지 않음
-> 클라이언트에서 서버에 정보를 보내는 것으로 족하고, 클라이언트에 대해서 새로운 정보를 보낼 필요가 없는 경우에 사용
- 200으로 응답하고 응답 body에 null, {}, [], false 등으로 응답하는 것과 다르다는 것이다.
- 204의 경우 HTTP Response body가 아예 존재하지 않는 경우다.
PUT
자원 수정 요청의 결과가 기존의 자원 내용과 동일하여 변경된 내용이 없을 때 204로 응답할 수 있다.
만약 수정 요청으로 자원의 내용이 변경된다면 201로 응답할 것이다.
DELETE
삭제 요청으로 자원을 삭제하여 더 이상 존재하지 않고 그 자원을 참조하는 모든 자원도 삭제되어, 더 이상 HTTP body를 응답하는 것이 무의미해졌을 때 사용한다.
출처: https://sanghaklee.tistory.com/61 [이상학의 개발블로그]
<206 Partial Content>
Range에 의해서 범위가 지정된 리케스트에 의해 서버가 부분적 GET 리퀘스트를 받았음을 나타냄
리스폰스엔 Content-Range로 지정된 범위의 엔티티가 포함되게 됨
- HTTP 206 Partial Content 성공 상태 응답 코드는 요청의 Range 헤더에 설명 된대로 요청이 성공했으며 본문에 요청 된 데이터 범위가 포함되어 있음을 나타냅니다 .
- 범위가 하나만있는 경우 전체 응답 의 Content-Type 이 문서 유형으로 설정되고 Content-Range 가 제공됩니다.
- 여러 범위가 다시 전송되면 Content-Type 은 multipart/byteranges 로 설정 되고 각 조각은 하나의 범위를 다루며 Content-Range 및 Content-Type 에서 설명합니다.
출처 : https://runebook.dev/ko/docs/http/status/206
처음에는 동영상 스트리밍에 대한 지식이 없어서 요청받은 파일 전체를 내려보냈습니다. 파일 크기가 작을 때는 상관없지만 크기가 큰 동영상을 이렇게 서비스할 수는 없습니다. 그럴 때 쓰는 것이 HTTP Range 헤더입니다. HTTP Range 헤더로 파일 전체가 아니라 조금씩 나눠서 보낼 수 있습니다.
웹 브라우저가 보내는 HTTP Range 헤더 요청은 다음과 같습니다.
출처 : https://www.3rabbitz.com/blog_ko/d9b3b3b10d2fee4a
3xx 리다이렉트
리퀘스트가 정상적으로 처리를 종료하기 위해 브라우저 측에서 특별한 처리를 수행해야 함을 나타냄
<301 Moved Permanently>
리퀘스트된 리소스에는 새로운 URI가 부여되어있기 떄문에 이후로는 그 리소스를 참조하는 URI를 사용해야한다는 것을 나타냄
<302 Found>
리퀘스트된 리소스에서 새로운 URI가 할당되어 있기 때문에 그 URI를 참조해주길 바란다는 의미
-> 301과 비슷하지만, 302는 일시적인 것
<303 See Other>
리퀘스트에 대한 리소스가 다른 URI에 있기 때문에 GET 메소드를 사용해서 얻어야한다는 것을 나타냄
-> 302와 비슷하지만, 302와 다르게 GET메소드로 얻어야 한다고 명확
<304 Not Modified>
클라이언트가 조건부 리퀘스트를 했을 때, 리소스에 대한 액세스는 허락하지만, 조건이 충족되지 않음을 표시
* 304는 리다이렉트랑 관련 X
<307 Temporary Redirect>
302랑 같지만, POST -> GET으로 변환 금지
HTTP Response Status Code는 요청에 대한 웹서버의 응답을 나타내는 코드를 말합니다. 이 코드를 바탕으로 웹브라우저나 검색엔진 크롤러는 요청을 어떻게 처리해야할지 판단하게 됩니다. 유명한 코드로는 404 Page Not Found가 있습니다. 301과 302 코드는 사용자를 새로운 URL로 이동시키는 코드입니다. 하지만 SEO측면에서 보면 단순한 페이지이동 외에 중요한 차이가 존재합니다.
브라우저가 Redirection 상태코드를 만나면 대부분 새로운 URL로 이동하게 됩니다. 하지만 검색엔진 크롤러가 Redirection 상태코드를 만나면 약간 다르게 동작합니다.
예를들어 기존 웹사이트를 새로운 주소로 옮겼다고 가정해 봅시다. 이 경우 예전 URL로 접속하면 새로운 주소로 이동하도록 리다이렉트 처리를 추가할 것입니다. 이때 검색엔진이 이전 URL이 보유하던 페이지랭크를 새로운 URL로 전달하게 하려면 301 리다이렉트를 사용해야 합니다.
301 혹은 영구이동(Permanently Moved)는 해당 URL이 영구적으로 새로운 URL로 변경되었음을 나타냅니다. 검색엔진 크롤러는 301 요청을 만나면 컨텐트가 완전히 새로운 URL로 영원히 이동했다고 판단합니다.
302 리다이렉트의 의미는 요청한 리소스가 임시적으로 새로운 URL로 이동했음(Temporarily Moved)을 나타냅니다. 따라서 검색엔진은 페이지랭킹이나 링크에 대한 점수를 새로운 URL로 옮기지 않으며 기존 URL을 그대로 유지합니다. 즉 검색엔진이 기존 URL이 보유한 페이지랭킹 점수는 그대로 유지하도록 하면서 컨텐트만 새로운 URL에서 조회하도록 해야할 때 유용합니다.
예를들어 쇼핑몰과 같은 전자상거래 사이트를 운영한다고 생각해봅시다. 인기리에 팔리는 제품이 일시적으로 재고가 떨어지거나 혹은 특정한 계절이나 기간에만 한정적으로 파는 제품이였다고 가정해봅시다. 해당 제품이 보유한 사이트랭크를 유지하면서 사용자에게 일시적으로 제품이 품절됐음을 알리려면 어떻게 해야할까요? 이럴 때 301을 사용하거나 혹은 페이지의 컨텐트를 변경하게 되면 사이트랭킹 점수가 달라지게 될 것입니다. 대신 302를 사용하게 되면 검색엔진은 일시적으로 해당 URL의 사이트랭크는 보존하게 되며 사용자는 새로운 URL의 컨텐트를 보게 됩니다.
SEO측면에서 보면 301과 302의 적절한 활용은 상당히 중요합니다. 부적절한 사용은 페이지랭크에 끔찍한 영향을 주게되며 해당 링크가 보유했던 높은 점수를 다시는 되찾지 못하게 될 수 있습니다.
출처: https://nsinc.tistory.com/168 [NakedStrength]
4xx 클라이언트 에러
클라이언트의 원인으로 에러가 발생했음을 나타냄
<400 Bad Request>
리퀘스트 구문이 잘못되었음을 나타낸다.
또 의외로 400 Bad Request는 그냥 “요청이 잘못되었다”라는 의미가 아니라 “요청의 syntax가 잘못되어서 이해를 못하겠다”라는 의미를 담은 응답
출처 : https://blog.npcode.com/2013/04/23/400-bad-request%EC%99%80-403-forbidden%EC%9D%98-%EC%9D%98%EB%AF%B8%EC%97%90-%EB%8C%80%ED%95%B4/
<401 Unauthorized>
송신한 리퀘스트에 HTTP 인증 정보가 필요하다는 것을 나타낸다.
또한 유저 인증에 실패했음을 표시한다.
401 인증되지 않은 오류를 수정하는 방법
1. URL의 오류를 확인하십시오 . URL 이 잘못 입력되었거나 클릭 한 링크가 잘못된 URL (권한이있는 사용자 만 해당)을 가리 키기 때문에 401 Unauthorized 오류가 표시되었을 수 있습니다.
2. URL이 유효하다는 확신이 들면 웹 사이트의 기본 페이지로 이동하여 로그인 또는 보안 액세스 라는 링크를 찾으십시오. 여기에 자격 증명을 입력하고 페이지를 다시 시도하십시오. 자격 증명이없는 경우 웹 사이트의 계정 설정 지침을 따르십시오.
4. 401 Unauthorized 오류는 로그인 직후에도 나타날 수 있습니다. 이는 웹 사이트에서 사용자 이름과 암호를 받았지만 무언가가 유효하지 않음을 나타냅니다 (예 : 암호가 잘못됨). 자신의 시스템에 다시 액세스하려면 웹 사이트의 모든 프로세스를 따르십시오.
출처 : https://ko.eyewated.com/401-%EC%9D%B8%EC%A6%9D%EB%90%98%EC%A7%80-%EC%95%8A%EC%9D%80-%EC%98%A4%EB%A5%98%EB%A5%BC-%EC%88%98%EC%A0%95%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95/
<403 Forbidden>
리퀘스트된 리소스의 액세스가 거부되었음을 나타낸다.
-> 파일 시스템의 퍼미션이 부여되지 않은 경우
- 액세스 권한에 문제(허가되지 않은 송신 IP 주소의 액세스 등)가 있는 경우
작동중인 서버에 클라이언트의 요청이 도달했으나, 서버가 클라이언트의 접근을 거부할 때 반환하는 HTTP 응답 코드이자 오류 코드이다.
이 에러는 서버 자체 또는 서버에 있는 파일에 접근할 권한이 없을 경우에 발생한다. 서버에는 외부 접근을 제어하기 위한 수많은 권한 설정이 있고, 서버에서 설정해 둔 권한과 맞지 않는 접속 요청이 들어오면 접근을 거부하고 접근거부 코드를 반환하는데, 이 때 뜨는 것이 바로 403 Forbidden 에러다.
아파치, IIS 등의 서버 소프트웨어에서 디렉토리 리스팅이 비활성화되어 있을 때 반환하기도 한다. 이것도 외부 접근을 제어하기 위한 권한 설정 중 하나.
대표적인 사례를 말하면 특정한 웹사이트가 특정한 국가나 IP 대역을 차단했을 때 차단당한 대상의 IP 및 지역에서 그 특정한 웹사이트를 들어가면 이게 뜬다. 이에 대한 해결책은 차단되지 않은 IP 대역으로 들어가면 된다.
프록시 서버, VPN 등의 문서를 참고하자. 사내 인트라넷 서버를 사내가 아닌 밖에서 접속하려고 할 때도 뜬다. 또한 주소창에 naver.com을 입력했는데, index.html이 없을 때도 나온다
출처 : https://namu.wiki/w/403%20Forbidden
<404 Not Found>
리퀘스트한 리소스가 서버상에 없다는 것을 의미한다.
404 오류는 서버를 찾지 못함을 의미하는 것이 아니라 서버는 찾았으나 해당 서버 내에서 파일을 찾지 못했을 때 리턴한다.
HTTP 오류 코드 중에서 가장 자주 보게 된다. 상술했듯이 서버에 없는 파일을 호출하면 튀어나오는데, 사소한 실수로도 이런 상황에 빠질 일이 가장 많기 때문이다. 하이퍼링크를 지정할 때 사소한 오타가 난다던지, 홈페이지를 업데이트하면서 파일을 삭제했는데 하이퍼링크는 여전히 삭제된 파일로 지정되어 있다던지 하는 일이 많기 때문이다. 특히 검색엔진의 경우 파일이 삭제되고나서 검색 봇이 다시 들를 때까지 이전 정보가 남아 있는 일이 많아서 자주 보게 된다.
자주 보이기 때문에 404 Not Found 페이지의 디자인에 공을 들이는 경우가 많다. 디자인 대회까지 열었을 정도. 당장 구글에 '404 Not Found Design'이라고 검색하면 수천가지의 세련되고 독특한 디자인이 나온다.
출처 : https://namu.wiki/w/404%20Not%20Found
5xx 서버 에러
서버 원인으로 에러가 발생하고 있을 의미한다.
<500 Internal Server Error>
서버에서 리퀘스트를 처리하는 도중에 에러가 발생하였음을 나타낸다.
<503 Service Unavailable>
서버가 과부화 상태이거나 점검 중이기 떄문에 현재 리퀘스트를 처리할 수 없음을 나타낸다.
상태가 해소되기까지 시간이 걸리는 경우에는 Retry-After 헤더 필드에 따라 클라이언트에 전달하는 것이 바람직하다.
- 서버 접속자가 많아 서버 접속 불가
- 접속은 하였으나 서버 응답을 받지 못하여 타임아웃 발생
- 서버 내 애플리케이션의 문제로 웹상에서 요청한 서비스가 정상 처리되지 못한 경우
일반적으로 503 에러는 첫번째 이유로 많이 발생합니다.
서버 과부하 또는 서버 폭주라고도 하는 이유로 발생 하는 겁니다.
출처 : https://jamesdreaming.tistory.com/34
참고
상태 코드가 현재 상황가 불일치할 수도 있다.
리스폰스로 되돌아오는 상태 코드의 대부분은 유저가 다른 내용을 알기 어렵게 되어있다.
흔한 상황으로는 어플리케이션 에러가 발생한 경우에도 상태 코드로는 200 OK로 되돌아오는 경우가 있다.