HTTP 요청/응답 헤더란?

브라우저에서 보이는 많은 데이터들은 HTTP 프로토콜에 의해 서버에서 브라우저로 데이터가 넘어오게 됩니다. 이때 요청(Request)을 보내고 응답(Response)를 받는다.

HTTP 헤더에는 브라우저, 서버, 요청 데이터의 정보가 함께 들어있고 전달한다. 그렇다면 헤더에 어떤 키-값이 있을까 ?

요청(Request) 헤더

:authority

:authority : :authority: github.com

: 가 앞에 붙는 이유??
HTTP/2에서는 : 로 시작하는 헤더 필드는 모두 예약된 헤더 필드로, 이들은 HTTP/2 프로토콜에서 사용하기 위해 미리 정의된 헤더 필드이다.

:method

HTTP 요청 메서드를 나타내는 헤더 필드. HTTP 요청 메서드는 클라이언트가 서버에게 요청하는 작업의 종류를 나타내며, 일반적으로 GET, POST, PUT, DELETE 등이 있다.

HTTP/1.1에서는 :method 대신에 실제 HTTP 요청 메서드를 사용하였지만, HTTP/2에서는 :method 헤더 필드가 추가되어 HTTP 요청 메서드를 명시한다. 이는 HTTP/2에서 다중 요청을 처리할 때 요청의 우선순위를 결정하는 데에 사용.

:method  :  GET | POST | PUT | DELETE

예를 들어, 클라이언트가 :method: GET 헤더 필드를 포함하는 HTTP/2 요청을 서버에 보낸다면, 해당 요청은 GET 메서드를 사용한 요청임을 나타내며, 서버는 이를 바탕으로 요청을 처리.

:path

HTTP 요청 URI를 나타내는 헤더 필드. HTTP 요청 URI는 클라이언트가 요청하는 리소스의 경로를 나타내며, 일반적으로 /path/to/resource와 같은 형식을 갖는다.

HTTP/1.1에서는 요청 라인에 URI가 포함되어 전송되었지만, HTTP/2에서는 요청 라인이 없기 때문에 :path 헤더 필드가 추가.
:path 헤더 필드를 사용하여 클라이언트는 요청하는 리소스의 경로를 서버에게 전달할 수 있다.

:path: github/index.html

예를 들어, 클라이언트가 :path: /index.html 헤더 필드를 포함하는 HTTP/2 요청을 서버에 보낸다면, 해당 요청은 /index.html 경로에 있는 리소스를 요청하는 요청임을 나타내며, 서버는 이를 바탕으로 요청을 처리.

:scheme

:scheme은 HTTP 요청이 사용하는 URI scheme을 나타내는 헤더 필드입니다. URI scheme은 클라이언트가 요청하는 리소스의 위치를 나타내는 URI의 첫 번째 부분으로, 일반적으로 http나 https와 같은 문자열을 갖는다.

:scheme: https

accept

클라이언트가 서버로부터 받고자 하는 콘텐츠 타입을 나타내는 헤더 필드이다. 클라이언트는 accept 헤더를 사용하여 서버가 제공할 수 있는 콘텐츠 타입을 나열하고, 서버는 이 중에서 클라이언트가 받고자 하는 콘텐츠 타입을 선택하여 응답한다.

accept 헤더의 값은 콤마로 구분된 하나 이상의 콘텐츠 타입을 포함합니다. 각 콘텐츠 타입은 MIME 타입으로 지정되며, 일반적으로 type/subtype 형식을 갖습니다. 예를 들어, application/json은 JSON 데이터를 나타내는 * MIME 타입입니다.

• MIME
  미디어 타입 (Multipurpose Internet Mail Extensions 또는 MIME type로도 알려져 있음)이란 문서, 파일 또는 바이트 집합의 성격과 형식을 나타낸다.

accept: text/html
accept: */* => 모든 요쳥 ok

accept 헤더는 HTTP 요청에서 자주 사용되며, RESTful API에서는 클라이언트가 서버로부터 받을 수 있는 콘텐츠 타입을 명시하는 데에 사용.

accept-Encoding

클라이언트가 서버로부터 받고자 하는 콘텐츠 인코딩을 나타내는 헤더 필드이다. 콘텐츠 인코딩은 서버가 콘텐츠를 압축하여 전송할 때 사용되며, 클라이언트는 accept-Encoding 헤더를 사용하여 서버가 지원하는 콘텐츠 인코딩을 나열한다.

accept-Encoding 헤더는 콤마로 구분된 하나 이상의 콘텐츠 인코딩을 포함합니다. 각 콘텐츠 인코딩은 압축 알고리즘으로 지정되며, 일반적으로 gzip, deflate, br 등이 사용된다.

accept-encoding: gzip, deflate, br

accept-Encoding 헤더는 HTTP 요청에서 자주 사용되며, 웹 브라우저에서는 콘텐츠를 더 빠르게 전송하기 위해 gzip 등의 콘텐츠 인코딩을 사용.

accept-language

클라이언트가 서버로부터 받고자 하는 언어를 나타내는 헤더 필드이다. 클라이언트는 accept-Language 헤더를 사용하여 서버가 제공할 수 있는 언어를 나열하고, 서버는 이 중에서 클라이언트가 받고자 하는 언어를 선택하여 응답한다.

accept-Language 헤더는 콤마로 구분된 하나 이상의 언어 태그를 포함한다. 각 언어 태그는 ISO 639 언어 코드로 지정되며, 일반적으로 en, ko, ja 등이 사용된다. 언어 태그 뒤에는 옵션으로 해당 언어의 지역을 나타내는 ISO 3166 국가 코드를 추가할 수 있다.

accept-Language 헤더는 HTTP 요청에서 자주 사용되며, 웹 브라우저에서는 사용자가 설정한 언어를 나타내기 위해 사용된다. 서버는 accept-Language 헤더를 사용하여 적절한 언어로 응답을 반환하며, 다국어 웹 사이트에서는 accept-Language 헤더를 사용하여 사용자가 원하는 언어로 콘텐츠를 제공한다.

accept-language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7,ja;q=0.6

authorization

클라이언트가 서버에게 자신의 인증 정보를 전달하는 헤더 필드이다. 보안이 필요한 리소스에 접근할 때 사용되며, 일반적으로 사용자 이름과 암호를 전송. authorization 헤더는 HTTP 요청에서만 사용된다.

authorization 헤더의 값은 일반적으로 Basic Authentication, Digest Authentication, OAuth 등의 인증 체계를 사용하여 생성된 인증 토큰이다. Basic Authentication의 경우 인증 토큰은 사용자 이름과 암호를 Base64로 인코딩한 문자열이다.

authorization: Bearer eyJhbGciOiJIUz...

Bearer는 Authorization 헤더에서 사용되는 인증 체계 중 하나이다. OAuth 2.0에서 정의되었으며, 토큰을 전달할 때 사용된다.

authorization 헤더는 HTTP 요청에서 자주 사용되며, RESTful API에서는 인증된 사용자만이 접근할 수 있는 리소스에 접근하기 위해 사용된다. 서버는 authorization 헤더를 사용하여 클라이언트의 인증 정보를 검증하고, 인증이 성공하면 요청된 리소스를 반환한다.

content-length

요청 본문의 길이

content-length: 10385

content-type

요청 본문의 미디어 타입을 나타낸다. accept와 비슷한데 content-type 헤더는 현재 전송하는 데이터가 어떤 타입인지에 대한 설명을 하는 개념이고 accept 헤더는 클라이언트가 서버에게 어떤 특정한 데이터 타입을 보낼때 클라이언트가 보낸 특정 데이터 타입으로만 응답을 해야한다.
또한 content-type은 요청/응답 둘다 사용 가능하다.

content-type: application/json

cookie

HTTP 요청에서 사용되는 헤더 필드 중 하나이다. 이 헤더는 클라이언트가 서버에 전송하는 쿠키를 나타낸다.

쿠키는 클라이언트 측에서 저장되는 작은 데이터 조각으로, 클라이언트가 서버에 요청을 보낼 때마다, cookie 헤더에 저장된 쿠키를 서버에 전송하여 사용자를 식별하고, 맞춤화된 경험을 제공한다.

cookie 헤더는 다음과 같은 형식으로 구성된다.

cookie: name1=value1; name2=value2; name3=value3

여기서, name1, name2, name3은 쿠키의 이름을 나타내고, value1, value2, value3은 쿠키의 값이다. 쿠키의 이름과 값은 서버에서 지정합니다. 쿠키의 이름과 값은 반드시 URL 인코딩이 필요하다.

예를 들어, 사용자의 로그인 정보를 저장하는 쿠키는 다음과 같이 cookie 헤더에 포함될 수 있다.

cookie: username=stone; sessionid=1234567890abcdef

이 경우, username은 쿠키의 이름이고, stone은 쿠키의 값이다. 마찬가지로, sessionid는 쿠키의 이름이고, 1234567890abcdef는 쿠키의 값이다.

Referer

HTTP 요청에서 사용되는 헤더 필드 중 하나이다. 이 헤더는 클라이언트가 현재 요청을 보내기 전에 방문했던 웹페이지의 URL을 나타낸다.

Referer 헤더는 다음과 같은 형식으로 구성된다.

Referer: https://www.example.com/page.html

여기서, https://www.example.com/page.html은 방문했던 웹페이지의 URL이다

일반적으로 웹사이트 분석 및 보안 목적으로 사용. 예를 들어, 웹사이트에서는 Referer 헤더를 사용하여 사용자가 해당 웹사이트에서 어떤 페이지로 이동했는지 추적할 수 있다. 또한, Referer 헤더는 웹사이트가 외부 링크를 통해 유입되는 트래픽을 추적하는 데 사용된다.

그러나, Referer 헤더는 사용자의 개인 정보 보호 문제가 있을 수 있으므로, 일부 브라우저에서는 Referer 헤더를 전송하지 않도록 설정할 수 있다.

User-Agent

HTTP 요청에서 사용되는 헤더 필드 중 하나이다. 이 헤더는 클라이언트가 사용하는 소프트웨어나 애플리케이션의 정보를 나타낸다.

User-Agent 헤더는 다음과 같은 형식으로 구성된다.

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

여기서, Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36은 클라이언트가 사용하는 브라우저의 정보이다.

User-Agent 헤더는 웹사이트가 클라이언트의 운영 체제, 브라우저 종류, 버전 등을 파악하여, 맞춤화된 경험을 제공하는 데 사용된다. 예를 들어, 모바일 기기에서 웹사이트를 열었을 때, 웹사이트는 User-Agent 헤더를 사용하여 모바일 버전의 페이지를 제공할 수 있다.

그러나, User-Agent 헤더는 사용자의 개인 정보 보호 문제가 있을 수 있으므로, 일부 브라우저에서는 사용자 에이전트 정보를 조작하거나 감추는 기능을 제공한다.

응답(Response) 헤더

cache-control

HTTP 요청 및 응답에서 사용되는 헤더 필드 중 하나이다. 이 헤더는 캐시 제어 지시자를 정의하여 캐시 동작을 제어한다.

cache-control 헤더는 다음과 같은 값으로 구성될 수 있다.

** cache-control **

no-cache : 캐시된 리소스를 사용하기 전에 해당 리소스를 검증해야 함을 나타낸다.
no-store : 리소스를 캐시하지 않아야 함을 나타낸다.
max-age : 리소스가 캐시될 최대 시간(초)을 지정한다.
public : 모든 사용자가 리소스를 캐시할 수 있도록 허용한다.
private : 리소스를 캐시할 수 있는 사용자를 제한한다.
must-revalidate : 캐시된 리소스를 사용하기 전에 해당 리소스를 검증해야 함을 나타내지만, 캐시된 리소스가 만료되었을 때만 검증한다.
proxy-revalidate : 프록시 서버가 캐시된 리소스를 사용하기 전에 해당 리소스를 검증해야 함을 나타내지만, 캐시된 리소스가 만료되었을 때만 검증한다.
no-transform : 리소스가 프록시에 의해 수정되어서는 안 된다는 것을 나타낸다.

cache-control 헤더는 웹 브라우저나 프록시 서버 등이 리소스를 캐시할 때 사용. 이 헤더는 캐시 동작을 제어하여 웹사이트의 성능을 향상시키는 데 도움을 준다.

** 브라우저 캐시에 대하여는 추후 포스팅 하려고 한다.

Content-Security-Policy(CSP)

웹 사이트에서 로드되는 콘텐츠의 출처를 지정하여 XSS(Cross-Site Scripting) 등의 공격을 방지하는 데 사용되는 보안 헤더이다.

CSP는 다음과 같은 지시자를 사용하여 구성된다.

default-src : 모든 리소스에 대한 기본 출처 지정자를 정의.
script-src : 자바스크립트 파일에 대한 출처 지정자를 정의.
style-src : CSS 파일에 대한 출처 지정자를 정의.
img-src : 이미지 파일에 대한 출처 지정자를 정의.
connect-src : XMLHttpRequest, WebSockets 등의 연결 요청에 대한 출처 지정자를 정의.
font-src : 웹 폰트에 대한 출처 지정자를 정의.
object-src : embed, object 등의 요소에 대한 출처 지정자를 정의.
media-src : 미디어 파일에 대한 출처 지정자를 정의.
frame-src : frame 및 iframe 요소에 대한 출처 지정자를 정의.
sandbox : 현재 문서가 실행될 때 적용할 보안 정책을 정의.

CSP를 사용하면, 웹 페이지에 로드되는 리소스의 출처를 명시적으로 지정함으로써 XSS 등의 공격을 예방할 수 있다. 웹 개발자는 CSP를 사용하여 웹 사이트의 보안을 강화할 수 있다.

Set-Cookie

서버에서 웹 브라우저로 쿠키를 생성하거나 수정할 때 사용되는 헤더.

Set-Cookie 헤더는 다음과 같은 값으로 구성된다.

name=value : 쿠키의 이름과 값.
Expires : 쿠키의 만료 일자.
Max-Age : 쿠키의 유효 기간을 초 단위로 지정.
Domain : 쿠키가 전송될 도메인을 지정.
Path : 쿠키가 전송될 URL 경로를 지정.
Secure : HTTPS 프로토콜을 사용하여 쿠키를 전송.
HttpOnly : 자바스크립트에서 쿠키를 접근할 수 없도록 한다.

Set-Cookie 헤더를 사용하면, 서버에서 웹 브라우저로 쿠키를 생성하거나 수정하여, 서버와 클라이언트 간의 상태 정보를 유지할 수 있다. 이를 통해, 로그인 정보, 사용자 환경 설정 등을 클라이언트 측에서 유지할 수 있다.

또한 응답 헤더에 set-cookie가 여러개가 존재할수가 있는데 이것은 쿠키를 여러개 생성하기 위한 것이다.

Access-Control-Allow-Origin

웹 브라우저에서 XMLHttpRequest나 fetch API 등을 통해 다른 도메인의 리소스를 요청할 때, 해당 리소스가 CORS(Cross-Origin Resource Sharing) 정책에 따라 접근 가능한 출처인지를 판단하기 위해 사용되는 응답 헤더.

이 헤더는 서버에서 클라이언트(웹 브라우저)로 보내지며, 다음과 같은 값으로 구성될 수 있다.

• Access-Control-Allow-Origin: * : 모든 출처에서 접근 가능하도록 허용.
• Access-Control-Allow-Origin: http://example.com : 특정 도메인에서만 접근 가능하도록 허용.

이 헤더로 지정된 출처만이 해당 리소스에 접근할 수 있다. 이를 통해, 다른 도메인에서의 CSRF(Cross-Site Request Forgery) 공격 등을 방지할 수 있다.

또한 CORS 보안정책을 회피할수 있게 한다.