HTTP 요청의 구조와 헤더의 역할

HTTP 요청의 기본 구조

HTTP 요청 메세지는 크게 세 가지로 나뉩니다.

1.  Request Line
   • 메서드 (GET, POST 등)
   • 경로 (Path)
   • 프로토콜 버전 (HTTP/1.1 등)
2. Headers
   • 요청의 메타정보를 담고 있습니다.
   • Key: Value 형태로 작성됩니다.
   • 여러 줄로 구성되며 순서는 상관하지 않습니다.
3. Body
   • 요청 데이터를 담고 있습니다
   • 예 :  로그인 정보, JSON 데이터 등

#예시
POST /admin HTTP/1.1                            #Request Line
HOST: 127.0.0.1                                 #Headers
User-Agent: Admin Browser
Content-Type: application/x-www-form-urlencoded
Content-Length: 12
DreamhackUser: admin
Cookie: admin=true
                                                #헤더와 바디는 빈 줄로 구분
userid=admin                                    #Body

헤더의 역할과 예시

필수적으로 사용되는 헤더

1. Host
   • 요청 대상 서버의 호스트 이름이나 IP가 들어갑니다.
   • HTTP/1.1 버전부터 필수적으로 들어가는 헤더입니다.
2. Content-Type
   • Body에 값이 들어간다면 필수적으로 작성되는 헤더입니다
   • Body에 담긴 데이터의 형식을 명시합니다.
3. Content-Length
   • Content-Type과 마찬가지로 Body에 값이 들어갔을 때 필수적으로 작성되는 헤더입니다.
   • Body에 들어간 데이터의 바이트 크기를 명시합니다.
   • 이 값을 통해 서버가 Body의 끝을 구분합니다.

자주 쓰는 기타 헤더

1. User-Agent
   • 클라이언트 정보가 들어갑니다.
2. Cookie
   • 말 그대로 Cookie값이 들어갑니다.
   • 주로 세션을 유지하기 위해 사용됩니다.
   • Key=Value 의 형태로 작성됩니다.
3. X-Forwarded-For
   • 프록시 서버를 거칠 때 원래 클라이언트의 IP를 담는 헤더입니다.
4. Authorization
   • 인증 토큰을 담는 헤더입니다.

Body와 Content-Length의 관계

Body에 값이 있을 때 서버는 어디까지가 Body인지 반드시 알아야합니다.

만약 Body의 끝이 재대로 명시되어있지 않으면 time out이 발생합니다.

서버가 Body의 끝을 알기 위하여 두 가지 방법 중 하나를 사용합니다.

1. Content-Length
   • Body의 크기를 바이트 단위로 명시합니다.
   • Content-Length : {int} 형태로 작성됩니다.
   • 대부분의 POST/PUT 요청에서는 Content-Length를 사용합니다.
2. Transfer-Encoding: chunked
   • Body를 조각(chunk) 단위로 보내는 방식에 사용됩니다.
   • 주로 대용량 전송에 사용되는 헤더입니다.

자주 사용되는 Content-Type과 의미

Content-Type은 Body에 들어있는 데이터의 형식을 서버에 알려주는 헤더입니다.

다양한 형식들이 있으며 서버가 이 값을 기준으로 어떻게 파싱할지를 결정합니다.

1. application/x-www-form-urlencode
   • HTML <form> 태그에서 가장 기본적으로 쓰는 방식입니다.
   • key1=value&key2=valu2 ... 의 형태로 Body를 작성합니다.
   • 데이터는 URL 인코딩 된다는 특징이 있습니다. 
   • 간단한 텍스트 전송에 적합한 방식입니다.
2. application/json
   • JSON 데이터를 전송하기 위해 사용되는 방식입니다.
   • {"key1": "value1", "key2": "value2" ... } 의 형태로 작성됩니다.
   • 클라이언트/서버 간 구조화된 데이터 교환에 적합한 방식입니다.
   • 일반적으로 UTF-8 인코딩이 되어 전달됩니다.
3. mutipart/form-data
   • 주로 파일 업로드를 위해 사용되는 방식입니다.
   • 한 번의 요청에 여러 종류의 데이터를 한 번에 보낼 수 있다는 장점이 있습니다.
   • 각 필드를 Boundary 구분자를 통해 나누어 표시하고, 때문에 복잡한 포맷을 따릅니다.
4. text/plain
   • 아무 포맷 없이 순수 문자열을 보내고 싶을 때 사용됩니다.

mutipart/form-data에 대한 추가 설명

여러 개의 데이터 블록(part)을 하나의 HTTP Body에 섞어 담기 위한 Content-Type입니다.

키와 값의 쌍 뿐만아니라 파일 데이터도 함께 보낼 수 있습니다.

1. 기본 구조와 핵심 개념
   • 각 파트는 --boundary 라는 구분자로 시작하여 구분됩니다.
   • 파트마다 고유의 헤더와 내용이 들어갑니다.
   • Body의 마지막은 --boundary-- 로 끝납니다.
2. 구성 요소
   1. boundary
      • 파트를 구분하기 위한 문자열 입니다.
      • 랜덤하게 생성됩니다.
      • 헤더에 반드시 표시되며 표시된 문자열과 동일한 문자열을 Body에 사용합니다.
      • 예) Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
   2. 각 파트
      • --{boundary}로 시작합니다.
      • 이때 boundary는 바로 위에서 설명한 것 처럼 랜덤하게 생성된 문자열을 뜻하며 헤더에 표시된 그 문자열을 그대로 사용합니다.
      • 파트 마다 Content-Disposition이라는 헤더가 Body내용에 포함됩니다.
      • name= {필드명}; filename= {파일명}; ... 로 작성됩니다.
      • 파일의 경우 Content-Type이 필수적으로 작성되어야 합니다.
      • 빈 줄로 실제 데이터와 헤더 값을 Body내에서 구분합니다.
   3. 예제) 파일과 폼 데이터 전송

POST /upload HTTP/1.1         #요청헤더
Host: example.com
Content-Type: multipart/form-data; boundary=---------------------------9051914041544843365972754266 #파트를 구분짓는 문자열

 

#요청 바디
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="userid"
              #파트 내에 헤더와 데이터는 빈 줄로 구분
admin         #userid의 값
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="file"; filename="upload.txt"
Content-Type: text/plain

(파일 콘텐츠 내용)
-----------------------------9051914041544843365972754266-- #Body의 끝은 boundary 문자열 뒤에 --을 붙여서 표기