[HTTP] HTTP Header1 (표현 Header, 협상 )

출처

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 강의 - 인프런

---

목차

 

HTTP 메시지의 구조

HTTP 헤더

• Header Field는 Field-name: OWS Field-Value OWS (OWS: 띄어쓰기 허용) 의 형식을 가지고 있습니다.
• Field-name은 대소문자를 구분하지 않습니다.

 

용도

• HTTP 전송에 필요한 모든 부가 정보를 나타냅니다.
• 예를 들어, 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트 정보, 서버 정보, 캐시 관리 정보 등을 나타냅니다.
• 표준 헤더는 굉장히 많습니다. (참고: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields)
• 필요시 임의의 헤더를 생성하여 추가할 수 있습니다. (ex) helloworld: hihi)

 

과거의 헤더 (RFC2616)

• Request Header : 요청 시의 헤더입니다. 예) User-Agent: Mozilla/5.0 (Macintosh; ..) (브라우저 정보)
• Response Header : 응답 시의 헤더입니다. 예) Server: Apache (서버 정보)
• General Header : 요청, 응답 구분 없이 메시지 전체에 적용되는 정보입니다. 예) Connection: close
• Entity Header : 엔티티 바디 정보를 나타냅니다. 예) Content-Type: text/html, Content-Length: 3424

 

과거의 바디 (RFC2616)

• 메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용됩니다.
• 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터를 의미합니다.
• 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공합니다.
  예) 데이터 유형(html, json), 데이터 길이 압축 정보 등

그런데, HTTP 표준이 1999년 RFC2616이 폐지가 되고, 2016년 RFC7230~7235가 등장했습니다.

 

 

RFC723x 로의 변화

• 엔티티(Entity) → 표현 (Representation) : 엔티티가 표현으로 변경되었습니다.
• 표현은 표현 메타 데이터와 표현 데이터를 합쳐서 지칭합니다.
  Representation = Representation Metadata + Representation Data
  (여기서 R이 Rest의 R입니다.)

 

RFC7230 (최신) - HTTP Body

• 메시지 본문(message body)를 통해 표현 데이터를 전달합니다.
• 메시지 본문은 페이로드(payload)라고도 부릅니다.
• 표현은 요청이나 응답에서 실제 전달할 데이터입니다. (표현 = 표현 헤더 + 표현 데이터)
• 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공합니다. 
  예) 데이터 유형(html, json), 데이터 길이, 압축 정보 등
• 리소스를 html이나 json으로 표현한다고 해서 표현이라는 단어를 사용했습니다.

 

표현 Header

• Content-Type : 표현 데이터의 형식
• Content-Encoding : 표현 데이터의 압축 방식
• Content-Language : 표현 데이터의 자연 언어
• Content-Length : 표현 데이터의 길이
  (사실 명확하게는 표현 헤더보단 페이로드 헤더가 더 맞습니다.)

 

Content-Type

표현 데이터의 형식을 설명합니다.

 

 

미디어 타입과 인코딩 방식을 나타냅니다. 예시로

• text/html; charset=utf-8
• application/json
• image/png

등이 있습니다.

 

 

Content-Encoding

표현 데이터의 인코딩 방식을 설명합니다.

 

• 표현 데이터를 압축할 때 사용합니다.
• 데이터를 전송하는 곳에서 압축 후 인코딩 헤더를 추가합니다.
• 데이터를 읽는 쪽에서 인코딩 헤더의 정보를 통해 압축을 해제합니다.
• 예시) gzip, deflat, identity (identy: 압축을 안한다는 의미)

 

Content-Language

표현 데이터의 자연 언어를 나타냅니다.

• 예시) ko, en, en-US

 

Content-Length

표현 데이터의 길이를 나타냅니다.

• 바이트 단위로 나타냅니다.
• Transfer-Encoding(전송 코딩)을 사용하면 Content-Length 헤더는 포함하면 안됩니다. 이유는 HTTP Header 2에서 설명합니다.

 

협상 (콘텐츠 네고시에이션)

헤더들을 사용하여 클라이언트가 선호하는 표현을 요청할 수 있습니다. 따라서 협상 헤더는 요청 시에만 사용합니다.

• Accept: 클라이언트가 선호하는 미디어 타입을 전달합니다.
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩 방식을 전달합니다.
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩 방식을 전달합니다.
• Accept-Language: 클라이언트가 선호하는 자연 언어를 전달합니다.  

 

Accept-Language 적용 전

• 한국어 브라우저를 사용하여 한국어로 받고 싶었으나 우선순위에서 밀려 영어로 된 표현을 전달받습니다.

 

Accept-Language 적용 후

• Accept-Language 헤더를 통해 한국어 표현을 전달받을 수 있습니다.

 

Accept-Language 복잡한 예시

• 브라우저에선 ko(한국어)를 원하는데, 서버에서 제공하는 언어 중에 한국어가 없을 경우엔 기본이 de(독일어)로 설정되어 있기 때문에 서버는 독일어를 전송합니다.
• 만약, 한국어가 없을 경우 영어를 받고 싶을 땐 어떻게 해야 할까요? 이때 필요한 것이 우선순위입니다.

 

협상과 우선순위

1. Quality Values(q)

• 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 생략)
2. ko;q=0.9
3. en-US;q=0.8
4. en;q=0.7

 

재전송

• 전과 달리 독일어 대신 영어를 전송합니다. 

 

▽ 참고 - 실제 구글에 hello 를 검색했을 때 보내는 요청 헤더 

 

 

2. 구체적인 것이 우선이다.

위의 예시의 우선순서대로 나타내면 다음과 같습니다.

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

 

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5