[HTTP 기초_1] 헤더 (요청(Request) 헤더, 응답(Response)헤더)

2. 웹개발/웹개발 기본

[HTTP 기초_1] 헤더 (요청(Request) 헤더, 응답(Response)헤더)

갓대희 2019. 1. 20. 18:19

[HTTP 기초_1] 헤더 (요청(Request) 헤더, 응답(Response)헤더)

안녕하세요. 갓대희 입니다. 이번 포스팅은 [ HTTP란?, HTTP 헤더 입니다. : )

헤더로 들어가기 앞서 HTTP가 무엇인지 부터 알아보자.

▶ HTTP란?

- HTTP는 Hyper Text Transfer Protocol의 약자

- 인터넷에서 데이터를 주고받을 수 있는 통신 규약

- 웹개발자라면 꼭 이해하고 넘어가도록 하자.

(웹 개발시 다양한 에러 코드를 마주하게 되는데 도움이 된다.)

(개발 하다보면 크롬 개발자 도구 네트워크 탭, 피들러등을 정말 많이 보게 될 것인데 이 패킷 해석에도 도움이 된다.)

▶ 요청(Request)

브라우저를 통해 http://goddaehee.tistory.com 에 대한 정보를 달라고 요청한다.

요청을 보낼때 요청에 대한 정보를 담아 서버로 보낸다.

GET http://goddaehee.tistory.com/168 HTTP/1.1

Host: goddaehee.tistory.com

Connection: keep-alive

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Referer: http://goddaehee.tistory.com/

Accept-Encoding: gzip, deflate

Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

Cookie: menuEnabled=1;

이런 정보를 HTTP 메시지라고 하며 시작줄, 헤더, 본문으로 구성된다.

(자세한 상세설명은 밑에서 다루도록 하겠다.)

첫번째 줄은 GET / HTTP/1.1(HTTP 버전)

두 번째 줄부터 헤더 (요청에 대한 정보)

▶ 응답

HTTP/1.1 200 OK

Date: Sun, 13 Jan 2019 17:28:13 GMT

Server: Apache

X-UA-Compatible: IE=Edge

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

P3P: CP='ALL DSP COR MON LAW OUR LEG DEL'

Access-Control-Allow-Origin: http://goddaehee.tistory.com

Vary: Accept-Encoding

Content-Length: 88052

Content-Type: text/html; charset=utf-8

이후 본문.........

첫번째 줄 200 OK는 요청성공

두 번째 줄부터 Request와 마찬가지로 헤더 정보이다.

여러 응답헤더가 있지만 특히 Cache-Control 덕분에 고생을 했던 적이 있는데 다음에 자세히 다루도록 해야겠다.

Response에선 헤더 이외에도 더 많은 정보가 있는데 이 부분이 본문이다.

요청시 데이터를 요청하면, 응답 메시지에는 요청한 데이터를 담아서 보내주는데 이 응답 메시지에 HTML이 담겨 있다. 이 HTML을 받아 브라우저가 화면에 렌더링한다.

▶ HTTP 메서드

크롬 주소창에 http://goddaehee.tistory.com 이라고 치는것

=> GET http://goddaehee.tistory.com HTTP/1.1 요청을 보내는 것과 같다.

이때 주소와 함께 HTTP 메서드를 같이 보낼 수 있는데 자주 쓰는 HTTP 메서드는 다음과 같다.

GET : 지정된 리소스(URI)를 요청

POST : 서버가 클라이언트의 폼 입력 필드 데이터의 수락을 요청. 클라이언트는 서버로 HTTP Body에 Data를 전송

HEAD: 문서의 헤더 정보만 요청하며, 응답데이터(body)를 받지 않는다.

PUT: 클라이언트가 전송한 데이터를 지정한 uri로 대체한다. ftp의 PUT과 동일하며, 클라이언트는 서버로 HTTP Body에 Data를 전송한다.

DELETE: 클라이언트가 지정한 URI를 서버에서 삭제한다.

TRACE: 클라이언트가 요청한 자원에 도달하기 까지의 경로를 기록하는 루프백(loop back) 검사용.클라이언트가 요청 자원에 도달하기 까지 거쳐가는 프록시나 게이트웨이의 중간 경로부터 최종 수진 서버까지의 경로를 알아낼때 사용.

- 이외 OPTIONS, HEAD, CONNECT 등등

서버가 설정에따라 해당 요청을 검증 후, 해당 요청이 유효하다면 실행된다.

- HTML기초 개발을 하다보면 자연스럽게 GET, POST라는 메서드는 많이 사용 해 보았을 것이다.

HTML 폼에서 GET과 POST를 사용할 수 있기 때문이다.

Action에 주소 설정하고 Method는 POST로 마지막에 해당 폼 Submit 한 경험이 다 있을 것이다.

실제로는 요청을 보낼 때에는 PUT, PATCH, DELETE 등 더 자세한 동작을 정의할 수 있다.

- 보통 PUT은 전체 수정, PATCH는 부분 수정, DELETE는 제거 요청 시 사용한다.

- GET, POST, PUT, PATCH, DELETE는 요청시 본문을 같이 보낼 수 있다.

- HEAD는 요청에서 헤더만 가져올 때 사용한다.

- OPTIONS는 서버가 어떤 메서드를 지원하는지 알아볼 때 사용한다.

CORS 상황에서 다른 도메인 서버에 먼저 OPTIONS 요청을 날린 뒤, 그 서버가 요청을 허용하면 실제 요청(GET, POST 등)을 날린다.

OPTIONS 요청은 그냥 간단하게 서버에 실제 요청을 보내기 전에 서버를 테스트해보는 용도라고 보시면 됩니다.

▶ 헤더

개발자도구(F12)의 네트워크 탭, 피들러 등을 통해 헤더들을 확인할 수 있습니다.

1. 공통헤더

- 요청과 응답에 모두 사용되는 헤더

1.1 Date

HTTP 메시지가 만들어진 시각입니다. 자동으로 만들어집니다.

ex) Date: Sun, 13 Jan 2019 17:28:13 GMT

1.2 Connection

일반적으로 HTTP/1.1을 사용하며 Connection은 기본적으로 keep-alive로 되어있다. 별 의미 없는 헤더.

ex) Connection: keep-alive

1.3 Content-Length

요청과 응답 메시지의 본문 크기를 바이트 단위로 표시해준다. 메시지 크기에 따라 자동으로 만들어진다.

ex) Content-Length: 88052

1.4 Cache-Control

이 녀석 때문에 하루 왠종일 고생했던 적이있다.

따로 캐시 다루는 부분에서 설명하도록 하겠다.

웹 뷰에서, 일반 모바일 브라우저에서 304라는 응답 코드를 주면 이녀석을 의심 해보자.

1.5 Content-Type

컨텐츠의 타입(MIME)과 문자열 인코딩(utf-8 등등)을 명시할 수 있다.

ex) Content-Type: text/html; charset=utf-8 (현재 메시지 내용이 text/html 타입이고 문자열은 utf-8 문자열)

서버로 데이터를 보낼 때는 text/html 대신 www-url-form-encoded, multipart/form-data 등이 Content-Type이 된다.

1.6 Content-Language

사용자의 언어.

ex) Content-Language=ja

(http://jpn.lottedfs.com/kr/display/category/third?dispShopNo1=1300091&dispShopNo2=1300092&dispShopNo3=1300093&treDpth=3)

롯데 면세 일본어 버전으로 접속시 다음과 같은 헤더정보를 볼 수 있다.

1.7 Content-Encoding

응답 컨텐츠를 br, gzip, deflate 등의 알고리즘으로 압축해서 보내면, 브라우저가 알아서 해제해서 사용한다.

이 외에도 다양한 압축 알고리즘이 존재한다.

요청이나 응답 전송 속도도 빨라지고, 데이터 소모량도 줄어들기 때문에 사용한다..

ex) Content-Encoding: gzip, deflate

Content-Encoding은 컨텐츠 압축된 방식입니다.

2. 요청헤더

2.1 Host

서버의 도메인 네임

Host 헤더는 반드시 하나가 존재해야 한다.

EX) host: goddaehee.tistory.com

2.2 User-Agent

가장 흔하게 보고 사용하는 헤더이다.

현재 사용자가 어떤 클라이언트(운영체제, 앱, 브라우저 등)를 통해 요청을 보냈는지 알 수 있다.

ex) User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Window로 크롬 브라우저를 통해 접속 하였다. 다만 헤더는 변경 할 수 있기 때문에 무조건 신뢰할 수는 없다.

그래도 매우 유용한 헤더이며 이를 활용하여 접속자 및 사용기기 통계를 내기도 한다.

2.3 Accept

클라이언트가 허용할 수 있는 파일 형식(MIME TYPE)

ex1) Accept: text/html (HTML 형식인 응답을 처리하겠다)

ex2) Accept: image/png, image/gif

ex3) Accept: text/*

콤마로 여러 타입을 동시에 적어줄 수도 있고, *(와일드카드)로 텍스트면 ok라고 요청할 수 있다.

위에 명시하였던 Content 헤더와 비교하여 보자.

Accept로 원하는 형식을 보내고, 서버가 응답하면서 헤더의 Content를 설정하게된다.

ex4)

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Accept-Encoding: gzip, deflate

Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

2.4 Cookie

웹서버가 클라이언트에 쿠키를 저장해 놓았다면 해당 쿠키의 정보를 이름-값 쌍으로 웹서버에 전송한다.

2.5 Origin

POST같은 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지를 나타내는데 이때 보낸 주소와 받는 주소가 다르면 CORS 문제가 발생하기도 한다.

ex) Origin : http://goddaehee.tistory.com

ex) Referer: http://goddaehee.tistory.com

2.6 If-Modified-Since

페이지가 수정되었으면 최신 버전 페이지 요청을 위한 필드

만일 요청한 파일이 이 필드에 지정된 시간 이후로 변경되지 않았다면, 서버로부터 데이터를 전송받지 않는다.

Cache-Control 과 함께 다시 보자. 얘네들 때문에 고생 많이 했으니 ....

이럴 때 서버로부터 304 상태코드를 전송받게 된다.

2.7 Authorization

Authorization 헤더는 인증 토큰을 서버로 보낼 때 사용하는 헤더.

API 요청같은 것을 할 때 토큰이 없으면 거절당하기 때문에 이 때, Authorization을 사용한다.

JWT(Json Web Token) 을 사용한 인증에서 주로 사용 한다.

ex) Authorization: Bearer xxx.xxx.xxx

3. 응답헤더

3.1 Server

웹서버 정보를 나타낸다.

3.2 Access-Control-Allow-Origin

요청 Host와 응답 Host가 다르면 CORS 에러가 발생하는데 서버에서 응답 메시지 Access-Control-Allow-Origin 헤더에 프론트 주소를 적어주면 에러가 발생하지 않는다.

ex) Access-Control-Allow-Origin: goddaehee.tistory.com