[HTTP] HTTP 상태코드

• HTTP 상태코드
  • 클라이언트가 보낸 요청의 처리상태를 알려주는 응답 형식
  • 1xx (informal) : 요청이 수신되어 처리중 - 거의 사용되지 않음
  • 2xx (successful) : 요청 정상 처리
  • 3xx (redirection) : 요청을 완료하려면 추가 행동 필요
  • 4xx (client error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없다
  • 5xx (server error) : 서버 오류, 서버가 정상 요청을 처리하지 못함
• 2xx (successful)
  • 200 OK- 성공
  • 201 Created - 요청성공해서 새로운 리소스 생성됨, 응답의 Location 헤더 필드에 URI가 첨부됨
  • 202 Accepted - 요청은 접수됐으나 아직 처리 완료안됨, 잘 사용하지 않음
  • 204 No Content - 요청은 수행했지만 응답 페이로드에 보낼 데이터가 없다. 데이터를 전송하고도 같은 화면을 유지할때 사용함 ( 웹 문서 편집기의 save 버튼 의 결과 성공/실패 이외의 내용은 중요하지 않음)
  • 성공해도 200, 201까지만 사용하는 경우가 많다.
• 3xx (redirection)
  • 요청을 완료하기 위해 유저 에이전트의 추가조치가 필요하다
  • 웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면 Location위치로 리다이렉트
  • 리다이렉트 : 영구 리다이렉션(301,308), 일시 리다이렉션 : PRG(Post Redirect Get), 특수 리다이렉션(응답 대신 캐시 사용)
  • 영구 리다이렉션 : 301, 308
    • 원래의 URL 사용하지 않음, 검색 엔진에서도 변경 인지
    • 301 Moved permanently : 리다이렉트시 요청 메소드가 GET으로 변하고 본문이 제거될 수 있다.
    • 308 Permanent Redirect : 301과 기능 동일, 리다이렉트시 요청 메소드, 본문 유지 - 거의 사용하지 않음
  • 일시적 리다이렉션 : 302, 303, 307
    • 리소스의 URI가 일시적으로 변경
    • 302 Found **: 리다이렉트 요청 메소드가 GET으로 변하고, 본문이 제거될 수 있다. - 대부분 변한다.(MAY)
    • 303 See Other **: 302와 기능이 같다, 리다이렉트 요청 메소드가 GET으로 변경된다. (MUST)
    • 307 Temporary Redirect **: 302와 기능이 같다, 리다이렉트 요청 메소드와 본문 유지
    • PRG(Post Redirect Get) : POST로 제품 주문 후에 주문 결과 화면을 GET 메소드로 리다이렉트, 새로고침해도 결과 화면은 GET 조회. 중복 주문 대신에 결과 화면만 GET으로 다시 요청 - 새로고침해도 GET으로 결과 화면만 조회. 서버에 오류가 줄어서 좋음
  • 기타 리다이렉션
    • 300 multiple choice : 사용 잘 안함
    • 304 Not Modified : 캐시를 목적으로 사용, 클라이언트에게 리소스가 수정되지 않음을 알려주고 클라이언트는 로컬에 저장된 캐시를 재사용한다. 응답에 메시지 바디가 없다. 조건부 GET HEAD 요청시 사용
• 4xx (Client Error)
  • 오류의 원인이 클라이언트에 있다.
  • 같은 요청을 다시 보내도 요청이 실패할 가능성이 높다.
  • 400 Bad Request : 요청 구문, 메시지 등의 오류. 요청을 재검토하고 보내야한다.
  • 401 Unauthorized : 인증이 되지않음. 인증과 인가 구분이 안되어있다.
    • 인증 Authentication : 로그인 여부
    • 인가 Authorization : 권한 부여 여부
  • 403 Forbidden : 서버가 요청을 이해했으나 승인을 거부함. 접근 권한이 없는 리소스에 접근했을 때 발생하는 오류
  • 404 Not Found : 요청한 리소스가 서버에 없음, 접근 권한이 없는 리소스에 접근할 때 리소스 존재 여부를 밝히고 싶지 않으면 보내는 response
• 5xx (Server Error)
  • 서버 복구 후 같은 요청을 다시보내면 요청이 성공할 가능성이 있다.
  • 500 Internal Server Error : 서버 내부의 문제로 오류 발생
  • 503 Service Unavailable : 서버의 일시적 과부하, 예정된 작업으로 잠시 요청을 처리할 수 없음을 표현 Retry - after 헤더 필드로 얼마 뒤에 복구되는지 보낼 수 도 있다. 503보다는 보통 500 사용
  • 웬만해서는 5xx에러 발생시키면 안된다. null pointer exception, db 오류가 아닌 이상 다른 오류로 설정해야 수정하기 용이함
• HTTP 헤더
  • HTTP 전송에 필요한 모든 부가정보
  • https://developer.mozilla.org/ko/docs/Web/HTTP/Headers
  • 필요시 임의의 헤더 필드 추가 가능
• 캐시와 조건부 요청
  • 캐시 기본 동작
    • 캐시가 없을 때 : HTTP 헤더와 HTTP 바디를 받아옴, 데이터가 변경되지 않아도 계속 네트워크를 통해 데이터를 받아야한다, 브라우저 로딩 속도가 느리다.
    • 캐시 적용시 : 네트워크를 사용하지 않아도 된다, 브라우저 로딩 속도가 빠르다
      1. cache-control 의 max-age 정보를 받아 응답 결과를 캐시에 저장한다.
      2. 두번째 요청시 캐시의 유효시간을 검증하고 캐시에서 데이터를 가져온다.
    • 캐시 시간 초과 :
      1. 캐시 유효 시간이 초과된 것을 확인
      2. 데이터 재요청 , 기존의 캐시 삭제후 새 데이터 캐시에 저장
• 검증 헤더와 조건부 요청 Last-modified
  • 캐시 유효 시간은 초과되었지만 데이터가 변경되지 않은 경우 → 데이터를 새로 전송받는 대신에 저장해두었던 캐시를 재사용할 수 있다.
    1. Last-modified 속성 확인 : 데이터가 마지막에 수정된 시간을 확인해서 기존 캐시와 비교
    2. 클라이언트에서 if-Modified-Since 속성에 기존 캐시의 데이터 최종 수정일을 넣어 전송
    3. 서버에서 if-Modified-Since 데이터를 검증후 데이터 미변경시 HTTP body가 없는 304 Not Modified 전송 (데이터 변경시 200 OK 와 데이터 재전송)
    4. 클라언트는 캐시에 저장되어있는 데이터 재활용
  • console → network → status 304 & request header의 if-modified-since로 확인 가능
• 검증헤더와 조건부 요청 - ETag
  • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우, 데이터 수정일자는 변경되었지만 데이터는 변경되지 않은 경우
  • 캐시용 데이터에 임의의 고유 버전 명을 넣는다. 데이터가 변경되면 이름을 변경한다. → ETag가 같으면 유지, 다르면 다시 받기
    1. 서버에서 ETag 값을 포함한 데이터를 전송
    2. cache-control 시간을 초과했으면 클라이언트에서 if-None-Match : ETag명 입력후 전송
    3. 서버에서 ETag명 확인후 일치하면 304 Not Modified 응답보냄
    4. 클라언트는 캐시에 저장되어있는 데이터 재활용
  • 어플리케이션 배포 주기에 맞추어 ETag를 모두 갱신하기도 함
• 캐시 제어 헤더
  • Cache-Control : max-age, no-cache(데이터는 캐시해도 되지만 항상 원 서버에 검증하고 사용), no-store(데이터에 민감한 정보가 있으므로 저장 불가)
  • Pragma : no-cahe(no-cahe와 동일하게 동작) HTTP 1.0 하위호환으로 현재 자주 사용하지 않음
  • Expires : 캐시 만료일을 정확한 날짜로 지정, Cache-Control : max-age 권장
• 프록시 캐시
  • 웹 브라우저가 직접 멀리있는 원 서버에 접근하는게 아니라 원 서버의 캐시정보를 갖고있는 근처의 프록시 캐시 서버(public cache)에 접근, 웹 브라우저에 private cache를 저장한다.
  • Cache-Control 속성
    • public : 응답이 public cache에 저장되어도 된다.
    • private (디폴트) : 응답이 개인의 웹 브라우저에만 저장되어야한다. private cache에 저장해야함.
    • s-maxage : 프록시 서버에만 적용된다.
• 캐시 무효화
  • 웹 브라우저에서 임의로 캐시를 하는 경우가 있기 때문에 캐시를 무효화하고싶다면 필수적으로 값을 설정해 응답해야한다.
  • Cache-Control : no-cache, no-store, must-revalidate(캐시 만료 후 최초 조회시 원 서버에 검증해야함, 원 서버 접근 실패시 반드시 504 오류발생 )
  • Pragma: no-cache