[HTTP] HTTP 헤더1 - 일반 헤더(2)

공부 내용을 정리하고 앞으로의 학습에 이해를 돕기 위해 작성합니다.

 

일반 정보 헤더

1. From

From 헤더는 유저 에이전트(클라이언트)의 이메일 정보를 나타낸다. 이 헤더는 일반적으로 잘 사용되지 않지만, 검색 엔진 같은 서비스에서 주로 사용된다.

• 예시: From: user@example.com
• 주로 요청에서 사용되며, 이를 통해 클라이언트의 이메일 정보를 알 수 있다.

2. Referer

Referer 헤더는 현재 요청된 페이지의 이전 웹 페이지 주소를 나타낸다. 사용자가 A 페이지에서 B 페이지로 이동할 때, B 페이지를 요청할 때 Referer: A를 포함해 요청한다.

• 유입 경로 분석에 활용할 수 있다.
• 주의: Referer는 원래 단어인 Referrer의 오타이지만, 그대로 표준으로 사용되고 있다.
• 예시: Referer: http://example.com
• 주로 요청에서 사용된다.

3. User-Agent

User-Agent 헤더는 클라이언트 애플리케이션의 정보를 담고 있다. 웹 브라우저, 운영체제 등 클라이언트의 환경 정보를 서버에 전달하며, 이를 통해 서버는 클라이언트가 어떤 브라우저, OS 등을 사용하는지 파악할 수 있다. 이는 특히 통계 정보 수집이나 브라우저 호환성 이슈 파악에 유용하다.

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36

 

4. Server

Server 헤더는 요청을 처리하는 서버의 소프트웨어 정보를 나타낸다. 클라이언트는 이를 통해 서버가 Apache, Nginx 등의 어떤 웹 서버 소프트웨어를 사용하는지 확인할 수 있다.

• 예시
  • Server: Apache/2.2.22 (Debian)
  • Server: nginx
• 주로 응답에서 사용된다.

5. Date

Date 헤더는 HTTP 메시지가 발생한 날짜와 시간을 나타낸다. 이는 서버가 메시지를 생성한 시점을 GMT(그리니치 표준시) 기준으로 나타낸다.

• 예시: Date: Tue, 15 Nov 1994 08:12:31 GMT
• 주로 응답에서 사용된다.

특별한 정보 헤더

1. Host

Host 헤더는 요청한 호스트 정보(도메인)를 나타낸다. HTTP/1.1에서는 필수 헤더로, 클라이언트가 특정 서버에 접속할 때, 그 서버가 여러 도메인을 처리하는 경우 어느 도메인에 대한 요청인지 명확히 구분해 준다. 이는 특히 하나의 IP 주소에 여러 도메인이 적용되어 있는 가상 호스팅 환경에서 유용하다.

• 예시: Host: www.google.com
• 주로 요청에서 사용되며, 필수로 포함되어야 한다.

가상 호스팅의 예시

서버에 여러 도메인(예: aaa.com, bbb.com, ccc.com)이 구동되고 있는 경우, 클라이언트가 Host 헤더를 통해 어떤 도메인을 요청하는지 명시해야 서버가 올바른 응답을 반환할 수 있다.

Host 헤더가 없는 경우

클라이언트가 GET /hello HTTP/1.1 요청을 보낼 때 Host 헤더를 포함하지 않은 상황이다. 이 경우, 서버는 IP 주소(200.200.200.2)를 통해 여러 도메인(aaa.com, bbb.com, ccc.com)을 관리하고 있지만, 어떤 도메인으로 요청이 들어왔는지 알 수 없기 때문에 요청을 처리할 수 없다.

결과적으로 서버는 어떤 도메인으로 요청을 처리해야 할지 모르게 된다.

 

Host 헤더가 있는 경우

클라이언트가 GET /hello HTTP/1.1 요청을 보낼 때 Host 헤더를 포함한 상황이다. 여기서 Host 헤더는 Host: aaa.com으로 설정되어 있으며, 이를 통해 서버는 이 요청이 aaa.com 도메인으로 보내진 것임을 알 수 있다.

결과적으로 서버는 요청을 올바르게 처리할 수 있게 된다.

2. Location

Location 헤더는 페이지 리다이렉션 시 사용된다. 3xx 응답 코드(특히 301, 302)에서 이 헤더가 있으면 클라이언트는 해당 Location의 URL로 자동 이동한다.

• 예시: Location: http://example.com/new-page
• 주로 응답에서 사용되며, 리소스가 새롭게 생성되었거나 이동되었음을 알린다.

3xx 및 201 응답과 Location

• 201 Created: 요청으로 인해 새롭게 생성된 리소스의 URI를 나타냄.
• 3xx Redirection: 요청을 자동으로 리다이렉션할 대상 리소스를 가리킴.

3. Allow

Allow 헤더는 허용 가능한 HTTP 메서드를 나타낸다. 서버는 이 헤더를 통해 클라이언트에게 어떤 HTTP 메서드를 사용할 수 있는지 알린다. 이 헤더는 주로 405 Method Not Allowed 응답과 함께 제공되며, 클라이언트가 사용 불가능한 메서드를 요청할 때 허용되는 메서드를 명시한다.

• 예시: Allow: GET, HEAD, POST
• 주로 응답에서 사용되며, 클라이언트가 허용된 메서드로 다시 요청할 수 있도록 한다.

4. Retry-After

Retry-After 헤더는 클라이언트가 다음 요청을 하기까지 기다려야 하는 시간을 나타낸다. 주로 503 Service Unavailable와 함께 사용되며, 서버가 일시적으로 서비스를 제공할 수 없을 때 클라이언트에게 재시도 가능한 시간을 알려준다.

• 예시
  • Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
  • Retry-After: 120 (초단위 표기)
• 주로 응답에서 사용되며, 클라이언트는 이 시간 이후에 다시 요청을 시도할 수 있다.

인증 헤더

HTTP 인증은 클라이언트가 서버에 접근할 때 자신의 신원을 증명하는 방식이다. 이를 위해 주로 두 가지 헤더가 사용된다. 

 

1. Authorization

Authorization 헤더는 클라이언트가 서버에 인증 정보를 전달할 때 사용된다. 이 헤더는 서버에 제공되는 인증 정보(예: 사용자명과 비밀번호)를 포함하며, 서버는 이를 통해 클라이언트의 권한을 확인하고 요청에 대한 접근을 허용할지 결정한다.

• 예시: Authorization: Basic xxxxxxxxxxxxxxxx
  여기서 "Basic"은 인증 방식(기본 인증)을 나타내고, 뒤의 xxxxxxxxxxxxxxxx는 Base64로 인코딩 된 사용자명과 비밀번호이다.
• 주로 요청에서 사용되며, 클라이언트가 서버에 인증을 요청할 때 필요한 정보를 포함한다.

2. WWW-Authenticate

WWW-Authenticate 헤더는 리소스 접근 시 필요한 인증 방법을 서버가 클라이언트에게 정의하여 제공하는 데 사용된다. 서버는 클라이언트가 적절한 인증을 수행하지 않으면, 401 Unauthorized 응답과 함께 이 헤더를 포함해 클라이언트에게 어떤 인증이 필요한지 알린다.

WWW-Authenticate: Basic realm="simple"
WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\""

• 위 예시에서 realm은 인증이 필요한 영역을 의미하며, 클라이언트가 인증해야 할 리소스나 시스템을 구분하는 데 사용된다.
• 주로 응답에서 사용되며, 클라이언트에게 어떤 인증 방법을 사용해야 하는지 지시한다.

401 Unauthorized 응답과 함께 사용

• 401 Unauthorized 응답은 클라이언트가 올바른 인증 정보를 제공하지 않았을 때 서버가 반환하는 상태 코드이다. 이와 함께 WWW-Authenticate 헤더가 제공되어, 클라이언트가 다음 요청 시 필요한 인증 정보를 어떻게 전달해야 할지 알려준다.

이 두 헤더는 HTTP 인증 과정에서 중요한 역할을 하며, 클라이언트가 서버 자원에 접근할 때 인증을 통해 권한을 확인받는 과정을 지원한다. Authorization은 클라이언트의 인증 정보를 서버에 전달하고, WWW-Authenticate는 클라이언트에게 필요한 인증 방법을 제공하여 접근을 제어한다.

 

쿠키

쿠키는 클라이언트와 서버 간의 요청과 응답을 통해 상태를 저장하고, 이후 클라이언트가 서버에 재접속할 때 정보를 유지하는 데 사용된다. 쿠키는 주로 로그인 세션 관리, 사용자 추적 등의 목적에 사용된다.

 

쿠키 미사용

HTTP는 Stateless(무상태) 프로토콜이다. 클라이언트와 서버가 요청과 응답을 주고받은 후, 그 연결은 종료되며, 서버는 이전 요청의 상태를 기억하지 않는다. 이로 인해 매번 클라이언트는 서버에 자신의 정보를 포함하여 요청을 해야 한다.

 

문제점

• 모든 요청에 사용자 정보를 포함해야 함
  클라이언트는 모든 요청마다 사용자 정보를 포함하여 요청해야 한다. 예를 들어 로그인 후에도 매 요청마다 사용자 정보를 보내야 서버가 클라이언트를 식별할 수 있다.
• 브라우저 종료 후 로그인 정보 상실
  사용자가 브라우저를 종료하고 다시 열면, 서버는 이전 상태를 기억하지 않기 때문에 사용자는 다시 인증 절차를 거쳐야 한다.

쿠키 미사용 상태에서의 요청 흐름

1. 처음 welcome 페이지 접근

• 클라이언트는 처음 서버에 /welcome 페이지 접근을 요청한다.
• 서버는 클라이언트의 정보를 기억하지 못하므로 기본적으로 "손님"으로 처리하여 응답을 보낸다.

2. 로그인 요청

• 클라이언트가 /login 페이지에서 자신의 사용자 정보를 담아 로그인 요청을 보낸다.
• 서버는 로그인 성공 메시지를 응답하지만, 여전히 상태를 유지하지 못한다.

 

3. 로그인 이후 다시 welcome 페이지 접근

• 사용자가 다시 /welcome 페이지를 요청할 때, 로그인 정보를 포함하지 않으면 서버는 클라이언트를 여전히 "손님"으로 처리한다. 이는 서버가 클라이언트의 상태를 유지하지 못하기 때문이다.

Stateless 특징

• 무상태(Stateless) 프로토콜
  HTTP는 클라이언트와 서버 간의 연결이 요청과 응답이 끝나면 끊어진다. 서버는 클라이언트의 상태를 기억하지 않으며, 각 요청은 독립적이다.
• 요청 시마다 상태를 유지하지 않음
  클라이언트가 다시 요청을 보낼 때마다 서버는 새로운 요청으로 처리한다. 이전 요청의 정보는 유지되지 않는다.

대안

1. 모든 요청에 사용자 정보 포함

쿠키를 사용하지 않는 경우, 매번 요청 시 클라이언트는 사용자 정보를 포함해야 한다.

• 이 방식은 사용자의 정보를 계속해서 요청 URL에 포함해야 하며, 이를 유지하기 위해 개발 과정에서 많은 불편함이 발생할 수 있다.

2. 모든 요청과 링크에 사용자 정보 포함

링크를 클릭할 때마다 사용자 정보를 계속해서 포함해야 한다.

문제점

• 개발 복잡성: 모든 요청과 링크에 사용자 정보를 일일이 포함해야 하므로 개발이 복잡해진다.
• 브라우저 재시작 시 정보 손실: 브라우저를 종료하고 다시 열면 서버는 클라이언트의 이전 상태를 기억하지 않기 때문에 다시 인증해야 한다.

이와 같은 문제를 해결하기 위해 쿠키가 도입되며, 쿠키를 통해 클라이언트와 서버 간의 상태를 유지할 수 있다.

 

1. 로그인 후 쿠키 저장

사용자가 로그인할 때, 서버는 클라이언트에게 Set-Cookie 헤더를 통해 쿠키를 전송한다. 클라이언트는 이 쿠키를 저장하여 이후 요청에 자동으로 쿠키를 포함시킨다.

• 클라이언트가 /login 요청을 보내며 로그인 시도
• 서버는 성공적으로 로그인되었다는 응답과 함께 Set-Cookie 헤더로 user=홍길동 쿠키를 클라이언트에 전달
• 클라이언트는 해당 쿠키를 저장소에 저장

2. 로그인 이후 쿠키 사용

이후 클라이언트는 서버에 추가 요청을 보낼 때, 저장된 쿠키를 자동으로 포함하여 요청을 보낸다. 서버는 쿠키를 통해 사용자의 상태를 유지하고, 이에 따라 적절한 응답을 제공한다.

• 클라이언트가 /welcome 페이지를 요청할 때, 자동으로 user=홍길동 쿠키를 포함하여 전송
• 서버는 쿠키를 확인하고, 홍길동님으로 맞춤 응답을 보낸다.

 

3 모든 요청에 쿠키 정보 자동 포함

쿠키가 저장된 후, 클라이언트의 모든 요청에는 자동으로 쿠키가 포함된다. 이를 통해 사용자는 매번 로그인 정보를 입력할 필요 없이 서버와의 상태를 유지할 수 있다.

• GET /board 요청에도 자동으로 user=홍길동 쿠키가 포함됨
• 서버는 해당 쿠키를 기반으로 사용자의 상태를 유지하고 맞춤 응답을 제공

쿠키의 주요 속성

1. 생명주기 (Expires, Max-Age)

• Expires: 쿠키가 만료되는 날짜를 지정. 지정된 날짜가 지나면 쿠키는 자동으로 삭제된다.
  • 예시: Set-Cookie: expires=Sat, 26-Dec-2020 00:00:00 GMT
• Max-Age: 쿠키가 만료되기까지의 시간을 초 단위로 지정.
  • 예시: Set-Cookie: max-age=3600 (3600초 동안 유지)

2. 도메인 (Domain)

• Domain 속성은 쿠키가 적용될 도메인을 지정한다.
  • 명시된 경우: 해당 도메인과 하위 도메인에서 쿠키에 접근 가능.
    • 예: domain=example.org 설정 시, example.org와 dev.example.org에서 쿠키 접근 가능
  • 생략된 경우: 현재 문서 기준 도메인에서만 쿠키 접근 가능.

3. 경로 (Path)

• Path 속성은 쿠키가 적용될 경로를 지정한다. 경로 이하의 모든 페이지에서 쿠키를 접근할 수 있다.
  • 예: path=/home 설정 시, /home 및 하위 경로에서 쿠키 접근 가능

보안 관련 속성

1. Secure

• Secure 속성이 적용되면 쿠키는 오직 HTTPS 연결에서만 전송된다.

2. HttpOnly

• HttpOnly 속성이 설정된 쿠키는 JavaScript에서 접근할 수 없으며, 오직 HTTP 요청을 통해서만 전송된다. 이를 통해 XSS 공격을 방지할 수 있다.

3. SameSite

• SameSite 속성은 쿠키가 설정된 도메인과 요청 도메인이 동일할 때만 쿠키를 전송하도록 설정하여, CSRF 공격을 방지한다.