[Network] HTTP 헤더

리퀘스트  HTTP 메시지

HTTP 메시지 헤더

• 클라이언트와 서버 처리에 필요한 주요정보 거의 다 여기 있다

개행문자

 

HTTP 메시지 바디

• 사용자와 리소스를 필요로 하는 정보가 있다

 

HTTP 헤더 필드 구조

헤더필드 명: 필드 값

• 일반 헤더 필드: 리퀘스트 메시지와 리퀘스트 메시지 둘 다 사용 됨
• 리퀘스트 헤더 필드: 리퀘스트 부가정보와 클라이언트 정보, 리스폰스의 콘텐츠 관련 우선순위 등 포함
• 리스폰스 헤더 필드: 리스폰스의 정보와 서버경로, 클라이언트 추가 정보요구 등 포함
• 엔티티 헤더 필드: 콘텐츠 갱신시간 등 엔티티 관련 정보 포함

HTTP/1.1 이외의 헤더 필드(비표준 헤더 필드)

• 쿠키와 Set-Cookie, Content-Disposition

End- to-end 헤더와 Hop-by-hop 헤더

HTTP 헤더필드는, 캐시와 비캐시 프록시 동작을 정의하기 위해 2가지 카테고리로 분류

1. End-to-end 헤더
   • 리퀘스트나 리스폰스의 최종 수신자에게 전송
   • 캐시에서 구축된 리스폰스 중 보존 되어야 하고, 반드시 다시 전송되어야 함
2. Hop-by-hop 헤더
   • 한 번 전송에 대해서만 유효
   • 캐시와 프록시에 의해서 전송되지 않는 것도 있음
   • Connection 헤더 필드에 열거해야 함
     • Connection
     • Keep-Alive
     • Proxy-Authenticate
     • Proxy-Authorization
     • Trailer
     • TE
     • Transfer-Encoding
     • Upgrade

 

응용 1 : 강의시간 자료 중에 리스폰스 헤더필드 해석

강의 시간에 api.http로 Send Request를 날렸다. 리스폰스 메시지의 헤더를 해석해보자

 

HTTP/1.1 200 OK HTTP 프로토콜 버전 1.1을 사용, 요청이 성공적으로 처리되었음(상태 코드 200 OK)

X-Powered-By: Express 서버가 Express.js 프레임워크를 사용하여 응답을 생성했음(선택적인 헤더로, 서버의 내부 구현정보 제공)

Content-Type: application/json; charset=utf-8 응답 본문의 내용이 JSON 형식, UTF-8 문자 인코딩을 사용하고 있음

Content-Length: 140 응답 본문의 길이가 140 바이트임. (클라이언트가 데이터를 얼마나 읽어야 하는지 알 수 있게 해줌)

ETag: W/"8c-yDWLu2PPS162ezmkGNikUkfdzrw"

• 이태그(ETag). 특정 버전의 리소스를 식별하는 고유한 값.
• W/ 접두사는 약한(weak) ETag를 나타내며, 리소스가 근사적으로 동일함을 의미
• 클라이언트는 ETag를 사용하여 캐시된 리소스가 최신인지 확인 가능

Date: Thu, 25 Jul 2024 06:38:22 GMT 응답이 생성된 날짜와 시간을 GMT 표준시로 나타냄

Connection: close 이 응답 후에 서버가 TCP 연결을 닫을 것임. 클라이언트는 이 정보로 연결 관리 방식을 결정할 수 있음

 

응용 2: 내 GitHub 사이트로 접속 후 요청/응답 헤더필드 해석

🤔내 GitHub 사이트로 들어가게 되면 어떠한 요청/응답 헤더를 받을까?

 

 

:method: GET HTTP 메서드. 클라이언트가 서버에 리소스를 요청하고 있음. (GET 메서드: 주로 데이터를 요청)

:scheme: https 요청이 HTTPS 프로토콜을 사용하여 보내지고 있음. (데이터가 암호화되어 전송됨)

:authority: github.com 요청을 받는 서버의 호스트 이름

:path: /clara-shin 요청하는 리소스의 경로. 

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

• 클라이언트가 서버로부터 수신할 수 있는 MIME 타입
• 우선 순위는 text/html, application/xhtml+xml, application/xml이 높고, 그 외 모든 타입은 우선 순위가 낮음

Accept-Encoding: gzip, deflate, br

• 클라이언트가 서버로부터 수신할 수 있는 콘텐츠 인코딩 방식
• 여기서는 gzip, deflate, br(Brotli) 압축 방식을 수용할 수 있음

Accept-Language: ko-KR,ko;q=0.9

• 클라이언트가 선호하는 언어
• 여기서는 한국어(ko-KR 및 ko)를 선호

Connection: keep-alive

• 클라이언트가 서버에 지속적인 연결을 유지하고 싶다는 의사를 나타냄
• 이를 통해 여러 요청을 하나의 TCP 연결로 처리할 수 있음

Cookie: _gh_sess=3NvvsACwt1dVQD....

• 클라이언트가 서버에 전송하는 쿠키 데이터
• 이 예시에서는 _gh_sess 쿠키가 포함(쿠키는 클라이언트와 서버 간의 상태 정보를 유지하는 데 사용)

 

 

Host: github.com 요청을 받는 서버의 호스트 이름(어떤 서버로 요청을 보내는지)

Referer:https://github.com/

• 클라이언트가 현재 요청을 보내기 전에 방문했던 URL
• 서버는 사용자가 어떤 경로를 통해 현재 페이지에 접근했는지 알 수 있음

Sec-Fetch-Dest: document 클라이언트가 서버에서 어떤 유형의 리소스를 요청하는지. 여기서는 문서(document)를 요청하고 있음

Sec-Fetch-Mode: navigate 클라이언트가 서버와 어떻게 상호 작용하는지. navigate: 클라이언트가 탐색을 위해 리소스를 요청하고 있음

Sec-Fetch-Site: same-origin 요청이 동일 출처(same-origin)에서 발생했음. 즉, 요청의 출처와 목적지가 동일한 도메인임을 의미

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15

클라이언트의 브라우저 및 운영 체제 정보를 포함. 여기서는 Mac OS X 10.15.7을 사용하는 Safari 17.5 브라우저

 

 

 

 

Cache-Control: max-age=0, private, must-revalidate 캐싱 동작을 제어

• max-age=0: 리소스가 즉시 만료됨. 클라이언트는 항상 서버로부터 새로운 복사본을 요청해야 함.
• private: 리소스가 특정 사용자에게만 캐시될 수 있음. 공유 캐시(예: 프록시 서버)에서는 캐시할 수 없음.
• must-revalidate: 만료된 리소스가 재검증 없이 사용될 수 없음. 캐시된 데이터가 만료되면 반드시 서버로부터 새로운 데이터를 받아야함.

 

Content-Encoding: gzip

• 응답 본문이 gzip으로 압축되었음
• 클라이언트는 응답을 수신한 후 이를 gzip 형식으로 디코딩해야 함

Vary: X-Requested-With, X-PJAX-Container, Turbo-Frame, Turbo-Visit, Accept-Encoding, Accept, X-Requested-With

• 서버가 클라이언트 요청 헤더의 특정 필드를 기반으로 서로 다른 응답을 제공할 수 있음
• 즉, 다음과 같은 헤더가 달라질 경우 서버는 다른 응답을 제공할 수 있음
  • X-Requested-With
  • X-PJAX-Container
  • Turbo-Frame
  • Turbo-Visit
  • Accept-Encoding
  • Accept
  • X-Requested-With