일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 캐시
- di
- Spring
- cache
- js
- dependency injection
- 의존성 주입
- 로그인
- Excel
- vue-cli
- HTTP 메서드
- HTTP
- Security
- Java
- 싱글톤
- DB
- Repository
- vuex
- 프로토타입
- BEAN
- VUE
- Kotlin
- 라이프 사이클
- JPA
- Vue.js
- thymeleaf
- Stateless
- Singleton
- javascript
- Setter
- Today
- Total
jhhan의 블로그
HTTP 헤더 본문
지난번 포스트에 이어서
이번 포스트에서도 HTTP 헤더에 대해서 알아보겠습니다.
이번에는 좀 더 자세히 알아볼 것입니다.
(분류되는 내용이 다른 블로그에서 정리한 것과는 다를 수도 있을 것 같습니다.)
1. 표현
표현과 관련된 헤더입니다.
1-1. Content-Type
- 표현 데이터의 형식을 설명하는 역할
- ex)
- Content-Type: text/html; charset=UTF-8
- Content-Type: application/json
- Content-Type: image/png
- 메세지 바디 부분에 무슨 내용이 들어가는지 표시합니다.
- 자주 사용됨
1-2. Content-Encoding
- 표현 데이터를 압축하기 위해 사용
- 데이터 전달 시 압축 후 헤더 추가
- 데이터를 받는 부분은 헤더 정보를 통해 압축 해제
- ex)
- Content-Encoding: gzip
- Content-Encoding: deflate
- Content-Encoding: identity → identity는 압축을 하지 않았다는 의미
1-3. Content-Language
- 표현 데이터의 자연 언어를 표현함
- ex)
- Content-Language: ko
- Content-Language: en
- 웹사이트에서 언어 변환을 할 때 이런 헤더를 통해 언어가 바뀔 수 있음
1-4. Content-Length
- 표현 데이터의 길이
- 바이트 단위로 표시함
- ex) Content-Length: 2345
주의) Transfer-Encoding(전송 코딩)을 사용하면 Content-Length 헤더는 쓰면 안됩니다.
(Transfer-Encoding에 Content-Length와 비슷한 정보가 들어가기 때문)
2. 협상
클라이언트가 선호하는 표현 요청입니다.
이 부분은 처음 접할 때 좀 어렵게 느낄 수도 있는 부분입니다.
협상 헤더의 경우 요청일 때만 사용합니다.
- Accept : 클라이언트가 선호하는 미디어 타입 전달
- Accept-Charset : 클라이언트가 선호하는 문자 인코딩 전달
- Accept-Encoding: 클라이언트가 선호하는 압축 인코딩 전달
- Accept-Language: 클라이언트가 선호하는 자연 언어 전달
이런 헤더들이 존재하고
이 헤더들에는 우선순위라는 것도 존재합니다.
우선순위는 0~1 사이의 값을 가지고, 우선순위는 1이 가장 높습니다.(0이 가장 낮음)
q를 사용해서 헤더에 표시합니다.
ex) Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
- 이 예시의 경우
- ko-KR;q=1 → 생략됨
- ko;q=0.9
- en-US;q=0.8
- en;q=0.7
- 이 순서로 언어 지원하는 것을 선호한다는 뜻입니다.
그러면 ko-KR이 가장 먼저 고려된 후
없으면 ko,
그 다음으로 en-US,
마지막으로 en을 고려하게 됩니다.
실제로 이런 식으로 보내지는 것을 쉽게 알 수 있습니다.
다음으로 구체적인 것이 우선순위가 높습니다.
ex) Accept: text/*, text/plain, text/plain;format=flowed, */*
- 이 예시의 경우
- text/plain;format=flowed
- text/plain
- text/*
- */*
- 순으로 우선순위를 가집니다.
물론 서버가 해당 헤더를 읽지 못하면 이런 정보들은 쓸모가 없습니다. ㅎㅎ
그래도 클라이언트가 이런 정보를 보내면
서버는 최대한 클라이언트가 요청한 정보와 근접한 정보를 보내줍니다.
3. 전송 방식
전송하는 방식에 대한 헤더입니다.
3-1. 단순 전송
- Content-Length 헤더 사용
- 메세지 바디에 담긴 내용의 길이를 명확히 알 수 있을 때 사용
- 한 번 요청으로 한 번에 모든 데이터를 받을 때 사용
3-2. 압축 전송
- Content-Encoding 헤더 사용
- 말 그대로 압축시켜서 전송할 때 사용
- 메세지 바디에 담긴 내용은 매우 짧아진다.
- 압축 해제할 때 필요하기 때문에 Content-Encoding 헤더가 필요함
3-3. 분할 전송(Transfer Encoding)
- 말 그대로 분할되어서 전송됨
- Transfer-Encoding 헤더 사용
- ex) Transfer-Encoding: chunked
- 이 때는 Content-Length 헤더를 사용하면 안 됨
- 분할되어 전송되기 때문에 전체 길이를 알기 힘듬
- 분할되어 올 때 각각의 길이 정보들을 받을 수 있음
3-4. 범위 전송
- Content-Range 헤더 사용
- 범위를 지정해서 전송함
- ex) Content-Range: bytes 1001-2000 / 2000
- 2000 바이트의 길이를 가지고 있는 데이터를
- 처음에 1000바이트만 받고
- 나머지 1000바이트를 다시 받아야 할 때
- 이런 방식으로 전송 받을 수 있음
4. 일반
단순한 정보를 포함하는 헤더와 관련되어 있습니다.
4-1. From
- 유저 에이전트의 이메일 정보 포함
- 검색 엔진 등에서 자주 사용
- '요청'에서 사용
- 잘 안 쓰임
4-2. Referer
- 이전 웹페이지의 주소를 나타냄
- 즉, 현재 요청된 웹페이지의 이전 웹페이지 주소를 나타낸다
- A →B 로 이동할 때 : B 요청 시 Referer: A를 포함해서 요청
- 유입경로 분석 가능
- '요청'에서 사용
- 많이 사용하는 헤더임
참고) Referrer가 맞는 단어인데 Referer라고 오타가 났다고 합니다.
근데 이걸 바꾸면 기존에 되던 것들이 안되기 때문에 냅둔다고 하네요 ㅎㅎ
4-3. User-Agent
- 유저 에이전트의 애플리케이션 정보 표시
- 즉, 클라이언트의 웹브라우저 정보를 표시한다고 보면 됨
- 통계 정보에서 많이 활용
- 어떤 브라우저에서 장애가 발생하는지 파악 가능
- '요청'에서 사용
4-4. Server
- 요청을 처리하는 Origin 서버의 소프트웨어 정보 표시
- 즉, 요청을 처리하는 진짜 서버를 의미함
- 실제로 요청은 다양한 프록시 서버, 캐시 서버 등을 거치기 때문에 사용되는 헤더
- '응답'에서 사용
- ex) Server: Apache/2.2.22 (Debian)
4-5. Date
- 메세지가 발생한 날짜 & 시간 표시
- 과거에는 요청 & 응답 모두 사용
- 현재는 응답에서만 사용
5. 특별
일반으로 보기에는 좀 더 특별한 의미를 포함하는 헤더입니다.
5-1. Host
- 요청한 호스트의 정보 표시
- 필수 헤더 → 꼭 알아야 하는 헤더임(몇 안되는 필수 헤더)
- 요청에서 사용
- 하나의 서버가 여러 도메인을 처리해야할 때 사용
host 헤더는 필수입니다.언제 필요한지 알아봅시다.
ex) 하나의 서버에서 여러 개의 도메인이 구동되는 경우
- 서버는 200.200.200.2 로 가정
- a.com | b.com | c.com 이라는 3개의 도메인이 구동 중
- 클라이언트(100.100.100.1로 가정)에서 서버로 요청
- 근데 Host 정보가 없다면 어디서 처리해야할 지 모름! - 구분할 방법 없음!
- 여기까지는 아직 IP로만 통신하기 때문
- Host: a.com 이라는 헤더가 추가되는 경우
- IP와 Host의 정보를 알기 때문에 어디서 처리해야하는지 알 수 있음
예전에는 Host 헤더가 없어서 이런 문제가 발생하는 경우 대단히 힘들었다고 하네요.
그래서 개정된 버전에서는 Host 헤더를 추가해서 이런 문제를 막았다고 합니다.
5-2. Location
- 페이지 리다이렉션 시 사용
- 응답코드 3XX와 관련이 있음
- 응답코드가 3XX인 경우 Location에 정보가 담겼다면
→ Location 위치로 자동 이동되게 함 - 응답코드 201에서도 마찬가지
5-3. Allow
- 허용 가능한 HTTP 메서드에 대한 내용 표시
- 응답코드 405(Method Now Allowed)와 같이 사용
- Allow: GET, PUT → POST를 사용하면 안됨
- 관련 헤더를 서버에서 구현하지 않은 경우가 많음
→ 이런 헤더가 있다는 것을 알면 좋음
5-4. Retry-After
- 유저 에이전트가 다음 요청을 하기까지 대기해야하는 시간 표시
- 응답코드 503인 경우, 서비스가 언제까지 사용불가인지 알림 가능
- ex)
- Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
- Retry-After: 120 (초단위 표기)
- 사용하기가 쉽지는 않음..
6. 인증
인증과 관련되는 헤더입니다. - 주로 로그인 관련..?
6-1. Authorization
- 클라이언트의 인증정보를 서버에 전달할 때 사용
- ex) Authorization: ~~~
- 참고로 인증과 관련된 메커니즘이 굉장히 다양함
→ 인증 방법에 따라 나타나는 내용이 달라짐 - 이 헤더에 인증과 관련된 값을 넣어주면 됨
6-2. WWW-Authenticate
- 리소스 접근 시 필요한 인증 방법 정의
- 응답코드 401(Unauthorized)과 같이 사용
- ex) WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple"
이렇게 HTTP 헤더에 대해 짤막하게 알아봤습니다.
다음 포스트는 쿠키에 관해 적어보려고 합니다.
그럼 포스트를 마칩니다.
출처 : 모든 개발자를 위한 HTTP 웹 기본지식 by 김영한
'HTTP' 카테고리의 다른 글
HTTP - 캐시(1) (0) | 2022.01.29 |
---|---|
HTTP - Cookie (0) | 2022.01.28 |
HTTP 헤더 & 바디 (0) | 2022.01.22 |
HTTP 메서드(3) (0) | 2022.01.16 |
HTTP 메서드(2) (0) | 2022.01.16 |