HTTP 웹 기본 지식(7) - 일반 헤더(1)

HTTP 헤더 개요

헤더의 구성

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용한다는 뜻.)(field_name에는 대소문자 구분이 없다.)

• HTTP 전송에 필요한 모든 부가정보를 담고 있다.
• 메시지 바디의 내용, 크기, 압축, 서버 정보 등등
• 필요시임의의 헤더를 추가할 수도 있다.

헤더 또한 HTTP가 발전하면서 그 내용도 조금씩 달라졌다.

과거의 HTTP 헤더 구성(RFC2616)

• General 헤더: 메시지 전체에 적용되는 정보
• Request 헤더: 요청 정보
• Response 헤더: 응답 정보
• Entity 헤더: "엔티티" 바디의 정보를 담고 있다. Entity는 HTTP 바디에 담기는 실제 데이터를 의미한다.(https://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html)
• 메시지 본문은 "엔티티" 본문을 전달하는데 사용했다.
• 엔티티 본문: 요청이나 응답에서 전달할 실제 데이터이다.(메시지 본문이 엔티티 본문을 담고 있는 격이다.)
• 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공해준다.(데이터의 유형, 길이, 압축 정보 등등)

그런데 이제 새로운 HTTP 표준으로 바뀌게 된다. RFC2616 -> RFC7230~7235

• 엔티티라는 것은 사라지고 표현(Representation)이라는 용어가 등장한다.
• Representation = representation Metadata + Representation Data
• 표현 메타데이터와 표현 데이터를 합친 것.

RFC7230

• 메시지 본문(message body)을 통해 표현 데이터를 전달한다.
• 메시지 본문은 페이로드(payload)라고도 한다.
• 표현: 요청이나 응답에서 전달할 실제 데이터이다.
• 표현 헤더: 표현 데이터를 해석할 수 있는 정보를 제공한다.(데이터 유형(html, json), 데이터 길이, 압축 정보 등등)
• 원래 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야 한다.

표현 헤더의 구성

• Content-Type: 표현 데이터의 형식
• Content-Encoding: 표현 데이터의 압축 방식
• Content-Language: 표현 데이터의 자연 언어
• Content-Length: 표현 데이터의 길이
• 표현 헤더는 전송할 때, 응답할 때 둘 다 사용한다.

Content-Type

• 미디어 타입, 문자 인코딩.(text/html; charset=utf-8, application/json, image/png)

Content-Encoding

• 표현 데이터를 압축하기 위해 사용한다.
• 데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가하고
• 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제한다.
• 예) gzip, deflate, identity

Content-Language

• 표현 데이터의 자연 언어를 표현(ko, en, en-US)

Content-Length

• 바디의 길이. 바이트 단위이다.
• Transfer-Encoding(전송 인코딩)을 사용한다면 Content-Length를 사용하면 안 된다.. 이미 전송 인코딩에 정보가 있기 때문에

협상 헤더(contents negotiation)라는 것이 있다.

• 협상 헤더는 요청 시에만 사용한다. 클라이언트가 선호하는 표현을 요청하는 것이다.
• Accept: 클라이언트가 선호하는 미디어 타입
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
• Accept-Language: 클라이언트가 선호하는 자연 언어

언제 협상 헤더가 필요한가

• 만약 Accept-Language가 없다면, 한국어 사용자가 어느 영어권 서버에 페이지를 요청하면 영어로 내어줄 것이다. 그런데 미리 Accept-Language를 적용해서, 서버에 페이지를 요청할 때 KO를 요청하면, 다중 언어를 지원하는 서버에서 한국어를 내어줄 것이다. 그런데 만약 한국어를 지원하지 않고, 영어를 지원하는 아랍어 사이트라면?? -> 우선순위(Quality Value)를 통해 서버가 한국어를 지원하지 않는다면, 영어라도 달라고 요청할 수 있다.
• Json. Xml 응답을 지원하는 경우에는 클라이언트마다 받고 싶은 데이터 형식이 다를 수 있다.

우선순위 <- 협상 시 사용한다.

• Quality Values(q)를 사용한다.
• 0부터 1까지. 클수록 높은 우선순위이다. 생략하면 1
• "Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7" <- 여기서의 우선순위는?
• 1. ko-KR;q=1 (q생략)
• 2. ko;q=0.9
• 3. en-US;q=0.8
• 4. en:q=0.7
• 위 경우 한국어를 지원하지 않으면 ko-KR, ko는 없어서 넘어갈 것이고, en-US를 지원하면 3순위인 en-US 값으로 페이지를 내줄 것이다.

또한 구체적인 것이 우선한다. 다음과 같이 미디어 타입을 요청했을 때의 우선순위는?

• Accept: text/*, text/plain, text/plain;format=flowed, */*
• 1. text/plain;format=flowed
• 2. text/plain
• 3. text/*
• 4. */*
• 4번은 3번을 포함, 3번은 2번을 포함, 2번은 1번을 포함하고 있다. 그렇다면 제일 구체적인 1번이 첫 번째 우선순위가 된다.

• 또 다른 예.
• Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5
• 부여되어 있는 q 값대로 우선순위가 정해진다.