📒 오늘의 공부
1. 그림으로 배우는 Http & Network
4장 결과를 전달하는 HTTP 상태 코드
1. 서버로부터 리퀘스트 결과를 전달하는 상태코드
- 상태코드의 역할: 클라이언트가 서버에 리퀘스트를 보낼 때 서버에서 그 결과가 어떻게 되었는지 알려주는 것
- '200 OK'처럼 3자리 숫자와 설명으로 나타냄
- 숫자의 첫 번째 자리는 리스폰스의 클래스를 의미
- 나머지 2자리는 분류가 없음
- 상태코드 클래스
- 1xx : Informational - 리퀘스트 처리중
- 2xx : Success - 리퀘스트 정상 처리
- 3xx : Redirection - 리퀘스트 완료를 위한 추가 동작 필요
- 4xx : Client Error - 서버가 리퀘스트를 이해 불가
- 5xx : Server Error - 서버가 리퀘스트 처리 실패
2. 2xx 성공(Success)
-
200 OK
-
클라이언트가 보낸 리퀘스트를 서버가 정상 처리
-
상태코드와 같이 돌아오는 정보는 메소드에 따라 달라짐
ex. GET 메소드 - 리퀘스트된 리소스에 대응하는 엔티티가 리스폰스로 보내짐
Head 메소드 - 엔티티 헤더 필드가 메시지 바디를 동반하지 않고 리스폰스로 돌아옴
-
Head 메소드는 실제 데이터 본문 없이 헤더 정보만을 요청하고 받아오는 메소드
-
엔티티 헤더 필드: HTTP 요청이나 응답의 헤더 부분에 포함되는 정보
-
-
204 No Content
- 서버가 리퀘스트를 정상적으로 처리했지만 리스폰스에 엔티티 바디를 포함하지 않음
- 브라우저에서 리퀘스트를 보내고 204 리스폰스를 수신 후에도 표시되어 있는 화면이 변하는 일이 없음
- 클라이언트에서 서버에 정보를 보내고 서버는 클라이언트에 대해서 새로운 정보를 보낼 필요 없는 경우에 사용
-
206 Partial Content
- Range로 범위가 지정된 리퀘스트에 의해서 서버가 부분적 GET 리퀘스트를 받았음을 의미
- 리스폰스에는 Content-Range로 지정된 범위의 엔티티가 포함
- Range 헤더는 클라이언트가 서버에게 원하는 리소스의 일부분만을 요청하는 경우에 사용되며 이것을 "부분적 GET 리퀘스트"라고 부른다.
3. 3xx 리다이렉트(Redirection)
-
301 Moved Permanently
- 리퀘스트된 리소스에 새로운 URI가 부여되어 있어 이후로는 그 리소스를 참조하는 URI를 사용해야 한다는 것을 나타냄
- 북마크하고 있는 경우에 Location 헤더 필드에서 가리키고 있는 URI에 북마크를 다시 하는게 좋다는 것을 나타냄
-> 만약 사용자가 북마크로 저장한 페이지의 URL이 301 상태 코드와 함께 변경된다면, 클라이언트는 서버가 "Location" 헤더 필드로 보낸 새로운 URL을 확인하고, 해당 URL을 다시 북마크해야 함을 의미
-
302 Found
- 301과 비슷하게 리퀘스트된 리소스에 새로운 URI가 할당되어 있어 해당 URI를 참조하라는 것을 나타냄
- 301과 다른 점은 페이지의 URI가 영구적인 이동이 아닌 일시적인 이동으로 앞으로 이동될 가능성이 있다는 것
- 북마크한 경우 301처럼 북마크를 변경하는 것이 아니라 302를 돌려준 페이지에 대해서 계속 북마크를 변경해야 함
-
303 See Other
- 리퀘스트에 대한 리소스는 다른 URI에 있어 GET 메소드를 사용해 얻어야 한다는 것을 나타냄
- 302와 비슷하지만 리다이렉트 장소를 GET 메소드로 얻어야 한다고 명확하게 되어 있는 점이 다름
- ex. POST 메소드로 액세스한 CGI 프로그램을 실행 후 처리 결과를 별도의 URI에 GET 메소드로 리다이렉트 시키고 싶은 경우에 사용
-> 302도 같은 일이 가능하지만 303을 쓰는 것이 바람직
-> 사용자가 폼을 제출하여 데이터를 서버로 전송하는 경우 POST 요청으로 데이터를 보낸 후에 그 결과를 별도의 URI에서 GET 요청으로 볼 수 있도록 리다이렉트하려면 303 상태 코드를 사용할 수 있음
- 서버는 클라이언트의 POST 요청을 처리하고 결과를 저장한 후, 303 상태 코드와 함께 "Location" 헤더 필드에 결과 페이지의 URL을 제공
- 클라이언트는 이 URL로 GET 요청을 보내 결과 페이지를 확인 가능
-
301, 302, 303 리스폰스 코드가 되돌아 오면, 대부분의 브라우저에서는 POST를 GET으로 바꾸어 리퀘스트의 엔티티 바디를 삭제하고 리퀘스트를 자동적으로 재송신하도록 되어 있다.
-
304 Not Modified
- 3xx지만 Redirect와 관계 없는 코드
- 클라이언트가 조건부 리퀘스트를 했을 때 리소스에 대한 액세스는 허락하지만 조건이 충족되지 않음을 표시
- 304의 경우 리스폰스 바디에 어떤 것도 포함되어 있어선 안 됨
- 304 Not Modified는 서버의 리소스가 변경되지 않았을 때 불필요한 데이터 전송을 방지하기 위해 사용 됨
- 클라이언트가 요청을 보내면, 서버는 리소스가 변경되었는지 여부를 확인하고, 변경이 없으면 상태 코드 304를 반환하여 클라이언트에게 리소스를 다시 다운로드하지 않아도 되는 것을 알림
- 클라이언트는 서버의 응답에 포함된 "ETag"나 "Last-Modified"와 같은 헤더 정보를 기반으로 브라우저에 캐시된 리소스를 그대로 사용함으로써 리소스를 다시 다운로드할 필요 없이 로컬 캐시를 사용하여 페이지 로딩 속도를 향상시킴
-
307 Temporary Redirect
- 302와 같은 의미지만 307에서는 브라우저 사양에 따라 POST에서 GET으로 치환하지 않음
- 클라이언트가 POST 요청을 보낸 경우에도 리다이렉트된 리소스로 POST 요청이 유지
- 브라우저가 더 정확한 의도를 유지하며 리다이렉트를 처리할 수 있도록 도와줌
4. 4xx 클라이언트 에러(Client Error)
-
400 Bad Request
- 리퀘스트 구문이 잘못되었음을 의미
- 리퀘스트 내용 재점검 후 재송신 필요
-
401 Unauthorized
- 송신한 리퀘스트에 HTTP인증(BASIC 인증, DIGEST 인증)정보가 필요하다는 것을 의미
- 브라우저에서 처음 401 리스폰스를 받은 경우에는 인증을 위한 다이얼로그가 표시 됨
- 401은 클라이언트가 요청한 리소스에 접근하기 위해서는 인증이 필요하다는 것을 의미
- 서버는 클라이언트가 요청한 리소스에 접근하기 위해서는 사용자 인증을 통해 신원을 확인해야 한다는 것을 알림
- 인증 정보는 보통 HTTP 헤더에 포함되며, BASIC 인증이나 DIGEST 인증과 같은 메커니즘을 통해 전달 됨
- 다이얼로그 표시: 브라우저는 사용자에게 인증을 위한 다이얼로그를 표시하여 사용자의 아이디와 비밀번호를 입력하도록 요구하고 이 인증 정보는 서버로 다시 전달되어 리소스에 대한 접근 권한이 확인 됨
-
403 Forbidden
- 리퀘스트된 리소스의 액세스가 거부되었음을 의미
- 서버 측은 거부의 이유를 명확히 하는 경우에 엔티티 바디에 기재해서 유저 측에 표시
- 403의 원인 예시
- 파일 시스템의 퍼미션이 부여되지 않은 경우:
서버의 파일 시스템에서 해당 리소스에 대한 액세스 권한이 설정되지 않은 경우 - 액세스 권한에 문제(허가되지 않은 송신 IP주소의 액세스 등):
서버에서 특정 IP 주소나 사용자에 대한 액세스를 허용하지 않는 경우
- 파일 시스템의 퍼미션이 부여되지 않은 경우:
-
404 Not Found
- 리퀘스트한 리소스가 서버상에 없음을 의미
- 서버 측에 해당 리퀘스트를 거부하고 싶은 이유를 분명히 하고 있지 않은 경우에도 사용
5. 5xx 서버 에러(Server Error)
- 500 Internal Server Error
- 서버에서 리퀘스트를 처리하는 도중 에러가 발생했음을 의미
- 웹 애플리케이션에 에러가 발생한 경우나 일시적인 경우
- 503 Service Unavailable
- 일시적으로 서버가 과부하 상태이거나 점검중이라 현재 리퀘스트를 처리할 수 없음을 의미
- 이 상태가 해소되기까지 시간이 걸리는 경우 'Retry-After' 헤더 필드에 따라 클라이언트에 전달하는 것이 바람직
- "Retry-After" 헤더 필드: 얼마 후에 클라이언트가 다시 요청을 보내야 하는지를 서버가 초 단위로 지정할 수 있음
ex. "Retry-After: 30": 클라이언트에게 즉시 요청을 다시 보내지 말고 30초 후에 다시 시도하라고 알려주는 것
프론트엔드 개발자