HTTP 헤더의 변화
1999년 RFC2616 -> 2014년 RFC7230~7235
엔티티 ( 헤더 + 본문) -> 표현 ( 데이터 + 메타데이터)서버가 응답 메시지를 보냈을 때를 예시로 들어보자
HTTP/1.1 200 OK ---표현 헤더 Content-Type Content-Length ---표현 데이터 <html> <body>...</body> </html>
표현 헤더의 종류
표현 헤더의 경우 전송(클라이언트)과 응답(서버) 둘다 사용한다
- Content-Type : 메시지 바디 형식
- Content-Encoding : 표현 데이터의 압축 방식
- Content-Language : 표현 데이터의 자연 언어
- Content-Length : 표현 데이터의 길이
표현 데이터 형식
- Content-Type : html, json, png
- Content-Encoding : gzip, deflate, identity
- Content-Language : ko, en, en-US
- Content-Length : 바이트 단위를 의미
협상
클라이언트가 선호하는 표현 요청으로, Content-Negotiation을 의미
협상 적용 전
GET /event
->
Content-Language: en
hello
협상 적용 후
GET / event
Accept-Language: ko
->
Content-Language: ko
안녕하세요
만약, 원하는 요청이 서버에서 지원하지 않을 경우 디폴트 값으로 서버는 응답
서버에서 지원하지 않을 경우를 대비해 우선순위를 줄 수 있음
ex) Accept-Language: ko-KR, ko;q=0.9, en-US;1=0.8
Language뿐만 아니라, Type에도 적용이 가능하다
전송 방식
- 단순 전송
- 압축 전송
- 분할 전송
- 범위 전송
1. 단순 전송
길이(Content-Length)를 알 수 있을때만 사용
HTTP/1.1 200 OK
Content-Type : ~
Content-Length : ~~
2. 압축 전송
HTTP/1.1 200 OK
Content-Type : ~
Content-Encoding : gzip
Content-Length : ~~
3. 분할 전송
Content-Type : ~
Transfer-Encoding : chunked
※ Content-Length 가 필요하지 않음
표현 데이터의 형식을
길이
내용
길이
내용
위와 같은 형식으로 보내는 방법
4. 범위 전송
응답 중에 오류로 중간에 끊기면 처음부터 보내야 하는 상황이 발생하므로
범위로 끊어서 보내는 방법
HTTP/1.1 200 OK
Content-Type : ~
Content-Rage: bytes a~b/b~c
표현 데이터가 포함하는 정보
1. From - 유저 이메일 정보
- 검색 엔진, 요청에서 사용
2. Referer - 이전 웹 페이지 주소
- 유입 경로 분석 가능
3. User-Agent - 유저 애플리케이션 정보
- 특정 브라우저 오류 발생시 로그 파싱으로 어떤 브라우저인지 확정 가능
4. Server - 오리진 서버의 SW 정보
5. Date - 메시지 생성 날짜
6. Host - 도메인
- 하나의 IP 주소에 여러 도메인이 적용 되어있을 경우 도메인을 특정하기 위해 반드시 필요한 것
7. Location - 리다이렉션
- 3xx 응답 결과에 Location 헤더가 있을경우 해당 위치로 자동 리다이렉트
8. Allow - 허용 가능한 HTTP 메서드
- GET, HEAD, PUT
9. Retry-After - 유저가 다음 요청하기까지 대기 시간
- 날짜 표기 ( 해당 날짜 이후 가동되도록 ), 초단위 표기 ( 시간 초 이후 가동)
