HTTP 메시지

• HTTP 메시지는 메시지 헤더 + 개행문자(CR+LF) + 메시지 바디로 구성된다.
• HTTP 메시지는 ASCII로 인코딩된 텍스트 정보이며 여러 줄로 구성되어있다.
• HTTP 메시지는 HTTP 통신의 기본 단위로 옥텟 시퀀스(Octet sequence, octet은 8비트)로 구성되며 HTTP 통신을 통해 전송된다.

 

• 메시지 헤더는 리퀘스트라인/상태라인, 헤더필드로 구성된다.
  • 리퀘스트라인: HTTP Method + URI + HTTP 버전
  • 리스폰스라인: 상태코드(ex: 200) + 상태코드설명(ex: OK) + HTTP 버전
  • 헤더필드는 요청/응답에 대한 내용과 속성을 나타내며 4가지 종류가 있다.
    • request 헤더 필드(Request Header)
    • response 헤더 필드(Response Header)
    • 일반 헤더 필드(General Header)
    • 엔티티 헤더 필드(Entity Header)

 

• 메시지 바디는 전송되는 데이터 그 자체를 의미하며, 요청/응답에 관한 엔티티 바디를 운반한다.
• 엔티티: 요청/응답의 payload로 전송되는 정보로 엔티티헤더+엔티티바디로 구성된다.
• HTTP로 데이터를 전송할 경우 인코딩(변환)을 실시함으로써 전송 효율을 높일 수 있다.
  • 단, 컴퓨터에서 인코딩 처리를 해야 하므로 CPU 등의 리소스는 보다 많이 소비하게 된다.
  • 콘텐츠 코딩(Content Codings): 엔티티 정보를 압축하여 송신하면 클라이언트 측에서 디코딩한다.
    (ex: gzip, compress, deflate, indentity)
  • 청크 전송 코딩(Chunked transfer Coding): 엔티티 바디를 분할하는 기능
  • 멀티파트: 여러 다른 데이터를 다루기 위한 기능
    • 이미지 등의 바이너리 데이터를 아스키(ASCII) 문자열에 인코딩하는 방법, 데이터 종류를 나타내는 방법 등
    • Content-Type: multipart/form-data 와 같이 하나의 메시지 바디 내부에 엔티티를 여러개 포함시켜 보낼 수 있다.
    • (Content-Type은 메시지 바디의 오브젝트 타입을 가리킴)
    • multipart/form-data에 대한 자세한 내용(https://velog.io/@shin6403/HTTP-multipartform-data-%EB%9E%80)
      • "이미지 파일을 전송한다고 해서 이메일에 첨부파일을 붙여 메일을 보내는 것처럼 png나 jpg 파일 자체가 전송되는 것이 아니다. 이미지 파일도 문자로 이뤄져 있기 때문에 이미지 파일을 문자로 생성하여 HTTP request body에 담아 서버로 전송하는 것이다."
    • form의 entype
      • application/x-www-form-urlencoded(default)
        모든 문자를 인코딩함
      • text/plain
        공백을 +로 변환되고 그 외 문자는 인코딩하지 않음
      • multipart/form-data
        모든 문자를 인코딩하지 않음. form요소가 파일이나 이미지를 서버로 전송할 때 주로 사용함.
  • 레인지 리퀘스트: 대용량의 데이터의 경우 범위를 지정하여 요청할 수 있다.
    (ex: Range: bytes =5001-10000)
    • 레인지 리퀘스트에 대한 리스폰스는 206 상태코드로 돌아온다.

 

• 쿠키를 위한 헤더필드
  • 쿠키: 브라우저에 데이터를 저장하기 위한 수단.
    브라우저에서 서버로 요청을 전송할 때 그 요청에 대한 응답에 Set-Cookie 헤더가 포함되어있는 경우, 브라우저는 Set-Cookie 에 있는 데이터를 저장하고, 이 저장된 데이터를 쿠키라고 부른다.
  • Set-Cookie: 서버에서 클라이언트의 상태 관리를 시작할 때 response로 전달함
  • Cookie: 서버로부터 수신한 쿠키를 이후 request에 포함하여 전달함
  • Set-Cookie 필드의 속성들
    • Expires:Date; 브라우저가 쿠키를 송출할 수 있는 유효기간
      (생략한 경우 브라우저 세션 유지 동안만 유효, 서버에서 삭제 불가, 유효기간이 지났을 경우 쿠키를 덮어쓰는 방법으로 삭제 가능)
    • Path=/; 쿠키를 송출하는 범위를 특정 디렉토리로 한정
    • Domain=.abc.co.kr; 쿠키가 유효한 사이트를 명시. 도메인명은 후방일치가 됨.
      • abc.co.kr를 대상으로 한 요청에만 쿠키가 전송된다.
      • 별도로 명시된 도메인이 없다면 쿠키를 보낸 서버의 도메인으로 설정된다.
      • 도메인을 기준으로 퍼스트 파티 쿠키(First-party cookies)와 서드 파티 쿠키(Third-party cookies)로 구분할 수 있다.
        • 퍼스트 파티 쿠키: 사용자가 접속한 페이지와 같은 도메인으로 전송되는 쿠키 
        • 서드 파티 쿠키: 사용자가 접속한 페이지와 다른 도메인으로 전송하는 쿠키
    • Secure; 웹페이지가 HTTPS에서 열렸을 때만 쿠키 송출 가능
    • HttpOnly; XSS로부터 쿠키의 도청을 막는 기능. JS를 경유해서 쿠키를 취득할 수 없게 한다.
    • SameSite=Lax; cross-site로 전송하는 요청의 경우 쿠키 사용을 특정 사이트로 제한
      • 이 속성을 통해 CSRF 공격 방지 가능
      • CSRF: 인증된 유저의 상태 갱신 처리를 강제로 실행시키는 공격
      • Lax(default): 동일 사이트 내 요청 또는 다른 사이트의 GET 요청으로 쿠키 전송
        • GET 요청만 가능한 이유: 서버의 상태를 바꾸지 않을거라고 기대되는 요청이므로.
        • 따라서 POST나 DELETE 요청의 경우 Lax 쿠키는 전송되지 않는다.
      • Strict: 동일 사이트 내 요청으로만 쿠키 전송. 따라서 CSRF를 100% 방지할 수 있으나 사용자 편의성을 저하할 수 있기 때문에 Lax가 기본값으로 변경됨(chrome 80버전부터)
        (ex: 결제, 인증 모듈 등의 서드 파티 시스템과 연계된 서비스가 정상적으로 동작하지 않을 수 있음)
        • 퍼스트 파트 쿠키만 전송됨.
      • None: 모든 사이트에서 쿠키 전송 가능. secure 속성이 추가된 상태에서 사용할 것.
      • 브라우저에서 기본 설정을 변경한 것은 크로스 도메인간 중요한 정보 유지는 CSRF 가능성이 있는 쿠키가 아닌 다른 안전한 방식으로 하기를 권장하기 때문.

 

• referrer policy (https://yceffort.kr/2020/09/referer-and-referrer-policy)

 

 

출처:
https://developer.mozilla.org/ko/docs/Web/HTTP/Messages,
그림으로 배우는 HTTP & Network Basic,
https://ifuwanna.tistory.com/223,
https://seob.dev/posts/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EC%BF%A0%ED%82%A4%EC%99%80-SameSite-%EC%86%8D%EC%84%B1/