[문과 코린이의 IT 기록장] HTTP - HTTP 일반 헤더 (HTTP 헤더 개요, 표현(Representation), 콘텐츠 협상 (Content Negotiation), 전송 방식, 일반 정보, 특별한 정보, 인증, 쿠키)
모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...
www.inflearn.com
[문과 코린이의 IT 기록장] HTTP - HTTP메서드 활용 (클라이언트에서 서버로 - 데이터 전송 , HTTP API
[문과 코린이의 IT 기록장] HTTP - HTTP메서드 활용 (클라이언트에서 서버로 - 데이터 전송 , HTTP API 설계 예시) 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의 실무에 꼭 필요한 HT.
vansoft1215.tistory.com
[문과 코린이의 IT 기록장] HTTP - HTTP 상태코드 (HTTP 상태코드란?, 1xx (Informational), 2xx (Successful), 3xx (
[문과 코린이의 IT 기록장] HTTP - HTTP 상태코드 (HTTP 상태코드란?, 1xx (Informational), 2xx (Successful), 3xx (Redirection), 4xx (Client Error), 5xx (Server Error)) 모든 개발자..
vansoft1215.tistory.com
1. HTTP 헤더 개요
header-field = field name : OWS fild-value OWS ( OWS : 띄어쓰기 허용 )
[ 요청 메시지 ]
| Host : www.google.com |
[ 응답 메시지 ]
| Content-Type : text/html; charset=UTF-8 Content-Length : 3423 |
1) HTTP 헤더 용도
- HTTP 전송에 필요한 모든 부가정보를 담는다.
ex. 메시지 바디의 내용 / 메시지 바디 크기 / 압축 / 인증 / 요청 클라이언트 / 서버 정보 / 캐시 관리 정보 ..
- 필요시 임의로 헤더를 추가할 수 있다.
ex. helloword : hihi ( 임의의 헤더는, 약속한 클라이언트-서버만 이해할 수 있다. )
2) 과거 HTTP 헤더 - RFC2616
- 과거 RFC2616버전에서는 헤더를 4가지로 분류했다.
(1) General 헤더 : 요청 메시지나 응답 메시지에 구분 없이, 메시지 전체에 적용되는 정보를 의미한다.
ex. Connection:close
(2) Request 헤더 : 요청을 보낼 때 들어가는 정보들을 의미한다.
ex. User-Agent : Mozilla/5.0 (Macintosh; ...)
(3) Response 헤더 : 응답을 보낼 때 들어가는 정보들을 의미한다.
ex. Server : Apache
(4) Entity 헤더 : 엔티티 바디에 들어가는 정보들을 의미한다.
ex. Content-type : text/html , Content-Length:3423
3) 현재 HTTP 스펙 - RFC7230
- 1999년 RFC2616이 폐기되었으며, 2014년에 RFC7230~7235로 스펙이 쪼개지면서 굉장히 많은 부분이 변화함.
* 엔티티(Entity)라는 용어가 사라지고, 표현(Representation)이라는 용어로 바뀌었다.
* 표현(Representation) = 표현 메타데이터(Representation Metadata) + 표현 데이터(Representation Data)
2. 표현(Representation)
* 표현 헤더는 전송, 응답에서 모두 다 사용된다.
1) Content-Type : 표현 데이터의 형식
- Content-body에 들어가는 내용의 미디어 타입 및 문자 인코딩 방식을 표현한다.
ex1. text/html; charset=utf-8
ex2. application/json
ex3. image/png
2) Content-Encoding : 표현 데이터의 압축 방식
- 표현 데이터를 압축할 때 주로 사용한다.
- 데이터를 전달하는 곳에서, 실제 message-body 부분을 압축한다. 이후, 서버에서 클라이언트로 해당 압축 파일을 포내면, 클라이언트는 Content-Encoding을 통해 무엇으로 압축했는지 파악한 후, 압축을 해제한다.
ex. gzip / deflate / identity(압축하지 않는다)
3) Content-Language : 표현 데이터의 자연 언어
- 표현 데이터의 자연 언어를 표현한다.
ex. ko / en / en-US
4) Content-Length : 표현 데이터의 길이
- 바이트 단위로 표현한다.
* 주의 : Transfer-Encoding(전송 코딩)을 사용할 때는, Content-Length를 사용하면 안된다.
3. 콘텐츠 협상 (Content Negotiation)
- 클라이언트가 선호하는 표현을, 가능하면 우선순위에 맞춰 달라고, 서버에게 요청하는 것.
* 협상 헤더는 요청시에만 사용한다.
- Accept : 클라이언트가 선호하는 미디어 타입 전달 요청
- Accept-Charset : 클라이언트가 선호하는 문자 인코딩 요청
- Accept-Encoding : 클라이언트가 선호하는 압축 인코딩 요청
- Accept-Language : 클라이언트가 선호하는 자연 언어 요청
ex1. Quality Values(q) 우선 예시
* Quality Values(q) 값 사용
ex2. 구체적인 것이 우선 예시
| GET / event Accept : text/*, text/plain, text/plain;formation=flowed, */* |
우선순위 1. text/plain; format=flowed
우선순위 2. text/plain
우선순위 3. text/*
우선순위 4. */*
ex 3. 구체적인 것을 기준으로, 미디어 타입을 맞춘다. => Quality값 찾기
| GET / event Accept : text/*;q=0.3 , text/html;q=0.7 , text/html;level=1 , text/html;level=2;q=0.4 , */*;q=0.5 |
| Media Type | Quality |
| text/html;level=1 | 1 (완전 일치. q값이 생략되었기 때문에 1) |
| text/html | 0.7 (완전 일치) |
| text/plain | 0.3 (부분 일치. text/*와 가장 비슷하므로 0.3) |
| image/jpeg | 0.5 (부분 일치. */*와 가장 비슷하므로 0.5) |
| text/html;level=2 | 0.4 (완전 일치) |
| text/html;level=3 | 0.7 (부분 일치. text/html과 가장 비슷하므로 0.7) |
4. 전송 방식
1) 단순 전송
- content-length값을 명확하게 알 수 있을 때 사용하는 전송방식이다.
- 요청하면 응답을 주는 일반적인 방식
2) 압축 전송
- 서버에서 gzip과 같은 압축을 통해 용량을 줄였을 때, 즉 Content-Encoding이 추가적으로 명시되었을 때 사용하는 전송 방식이다.
3) 분할 전송
- 용량이 너무 큰 자료들일 경우, 한 번에 응답하고자 하면 대기 시간이 너무 길어지기 때문에, 분할 전송을 통해 받는 즉시 그 부분이라도 표현할 수 있도록 전송하는 방식으로, 사용자 편의성을 높일 수 있다.
- 분할 전송의 경우에는 content-length를 넣으면 안 된다.
a. 명확하게 content-length의 길이를 예상할 수 없다.
b. byte정보들이 chunked마다 존재하기 때문에, 보내면 안된다.
4) 범위 전송
ex. 자료를 다운받다가, 절반정도 받고 끊겼을 때, 다시 처음부터 요청하게 되면 용량이 너무 많이 사용된다. 따라서 처음부터 모두 다운받는 것이 아니라, 범위 전송의 기능을 통해 나머지 부부을 요청하는 방식으로 사용된다.
5. 일반 정보
- 단순한 정보성 헤더들
1) Form
- 유저 에이전트의 이메일 정보 * 일반적으로 잘 사용되지 않음
ex. 검색 엔진에서, 내 사이트를 크롤링 하는 것을, 즉 내 사이트로 들어오지 못하게 하는 것을 검색 엔진 담당자들에게 요청 할 때 사용
2) Refer
- 현재 요청된 페이지의 , 이전 웹 페이지 주소 * 요청에서 사용됨 (굉장히 자주 사용되는 정보성 헤더)
- Refer를 사용해서 유입 경로를 분석할 수 있다.
ex. A -> B로 이동하는 경우, B 페이지를 요청할 때 Refer:A를 포함해서 요청한다.
3) User-Agent
- 유저 에이전트 애플리케이션 정보. 즉 클라이언트의 애플리케이션 정보. ex. 웹 브라우저 정보
* 요청에서 사용됨
ex. 특정 브라우저에서 문제가 생길 경우, 서버가 어떤 브라우저에서 장애가 발생하는지 파악하는데 사용된다.
4) Server
- 요청을 처리하는 오리진 서버의 SW 정보
* 오리진 서버 : 내 http에 대한 응답 메시지를 보내주는 마지막에 있는 서버 (애플리케이션 표현 데이터를 찾아주는 서버)
- http 요청을 보낼 경우, 여러 개의 프록시 서버(캐시 서버 등..)을 중간에 거치게 됨.
* 응답에서 사용됨
5) Data
- 메시지가 생성된 날짜
* 응답에서 사용됨
6. 특별한 정보
1) Host
* 요청에서 사용됨
- 요청한 호스트 정보(도메인)를 남긴다.
- 하나의 서버가 여러 도메인을 처리해야 할 때, 즉 하나의 IP주소에 여러 도메인이 적용되어 있을 때 사용한다.
2) Location
- 201(createed) : Location값은 요청에 의해 생성된 리소스 URI임.
- 3xx(Redirection) : Location값은 요청을 자동으로 리디렉션하기 위한, 대상 리소스를 가리킨다.
* 웹 브라우저는 3xx응답 결과에 Location헤더가 있으면, Location위치로 자동 이동한다. (리다이렉트)
* 상태코드 3xx 페이지 리다이렉트 참고
[문과 코린이의 IT 기록장] HTTP - HTTP 상태코드 (HTTP 상태코드란?, 1xx (Informational), 2xx (Successful), 3xx (
[문과 코린이의 IT 기록장] HTTP - HTTP 상태코드 (HTTP 상태코드란?, 1xx (Informational), 2xx (Successful), 3xx (Redirection), 4xx (Client Error), 5xx (Server Error)) 모든 개발자..
vansoft1215.tistory.com
3) Allow
- HTTP 405오류(Method Not Allowed)에서, 응답 메시지 부분에 허용 가능한 HTTP 메서드에 대한 설명을 포함할 때 사용한다.
ex. Allow : GET / HEAD / PUT
* 실제로 이를 많이 구현하지는 않음
4) Retry-After
- HTTP 503오류(Service Unavailable)에서 서비스가 언제까지 불능일지, 즉 유저 에인트가 다음 요청을 하기까지 얼마나 기다려야하는지 시간을 나타내주는 역할을 한다.
7. 인증
1) Authorization
- 클라이언트 인증 정보를 서버에 전달할 수 있다.
2) www-Authenticate
- 401 Unauthorized응답과 같이 사용되며, 리소스 접근시 필요한 인증 방법을 정의해주는 역할을 한다.
8. 쿠키
- Set-Cookie : 서버에서 클라이언트로 쿠키를 전달한다. ( 응답 )
- Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달한다.
1) 쿠키 미사용시 문제점
- HTTP는 무상태(Stateless) 프로토콜이다. 따라서 클라이언트와 서버가 요청과 응답을 주고 받는 것이 완료가 되면 연결이 끊어진다.
- 따라서 클라이언트가 다시 요청을 했을 때, 서버는 이전 요청을 기억하지 못한다. (상태를 유지하지 못한다)
2) 대안1 - 쿠키 미사용 대안
- 모든 요청에 사용자 정보 전체를 넣어서 보내기.
- 문제점
: 개발시 모든 요청과 링크에 사용자 정보를 포함하는 것이 어려울 뿐더러, 보안상의 측면에서도 문제가 많다.
: 또한 브라우저를 완전히 종료하고 다시 열 때마다, 다시 모든 값을 넣어야 한다.
3) 대안2 - 쿠키 사용 대안
- 지정한 서버에 대해서는, 쿠키 데이터를 자동으로 모두 담아서 보내주는 방식으로 해결한다.
4) 쿠키
(1) 쿠키 사용 사례
a. 사용자 로그인 세션 관리
b. 광고 정보 트래킹
(2) 쿠키 사용 주의점
- 쿠키 정보는 항상 서버에 전송된다. 이 때문에, 네트워크 트래픽이 추가적으로 유발되는 것은 필수적이다. 따라서 최소한의 정보(세션 id, 인증 토큰)만 쿠키로 사용하도록 한다.
* 쿠키와 같은 기능을 사용하고는 싶지만, 요청할 때마다 서버에 보내는 것이 아닌, 클라이언트가 정보들을 들고 있다가 웹 브라우저 로직에서 js가 필요한 정보를 추출하는 방법으로 사용하고 싶다면? => 웹 스토리지(localStorage / sessionStorage)를 사용한다.
* 주의 : 보안에 민감한 데이터는 웹 스토리지에 저장하면 안 된다. ex. 주민번호, 신용카드 번호 등
(3) 쿠키 종류
a. 세션 쿠키 : 만료 날짜를 생략하면, 브라우저 종료시 까지만 유지된다.
b. 영속 쿠키 : 만료 날짜를 입력하면, 해당 날짜까지 유지된다.
(4) 쿠키 구성
ex. set-cookie : sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
a. Expires : 쿠키 만료 시간
- GMT 기준으로 넣어줘야 한다.
- expires 말고, max-age를 통해 초 단위로도 설정 가능하다
ex. expires = Sat, 26-Dec-2020 00:00:00 GMT;
b. Path: 쿠키 허용할 경로
- 지정한 경로 포함 하위 경로 페이지만 쿠키 접근이 가능하다.
- 일반적으로 한 도메인 내에선, 쿠키를 모두 다 전송하는 방식으로 구성되기 때문에, path=/로 지정된다.
ex. path=/home지정시
- /home : 가능
- /home/level1 : 가능
- /hello : 불가능
c. Domain : 쿠키 허용할 도메인
- 내가 지정한 쿠키가, 모든 사이트에 들어갈 때마다 정보가 전달되면 문제가 생긴다. 따라서, 쿠키는 허용할 도메인을 지정할 필요가 있다.
ex .domain = google.com;
| 1. 도메인을 명시할 경우 : 명시한 문서 기준 도메인 + 서브 도메인 포함 쿠키 접근 가능. (google.com은 물론이고, dev.google.org도 쿠키에 접근 가능함) 2. 도메인을 생략할 경우 : 현재 문서 기준 도메인만 적용 가능하다. (google.com에서 쿠키를 생성하고, domain지정을 생략했다면, google.com에섬나 쿠키 접근 가능) |
d. Secure : 쿠키 보안 정보
| 1. Secure - 원래 쿠키는 http / https를 구분하지 않고 전송하지만, Secure를 적용하면 https인 경우에만 서버로 쿠키 전송이 가능하다. 2. HttpOnly - js에서 쿠키에 접근을 불가능하도록 하고, http전송에서만 사용할 수 있도록 한다. (XSS공격을 방지한다) 3. SameSite - 요청 도메인과 쿠키 설정 도메인이 같은 경우에만, 쿠키를 전송할 수 있다. (XSRF공격을 방지한다) |
| * 유의사항 - 아직 공부하고 있는 문과생 코린이가, 정리해서 남겨놓은 정리 및 필기노트입니다. - 정확하지 않거나, 틀린 점이 있을 수 있으니, 유의해서 봐주시면 감사하겠습니다. - 혹시 잘못된 점을 발견하셨다면, 댓글로 친절하게 남겨주시면 감사하겠습니다 :) |
