http 일반 헤더 (쿠키?)

HTTP 헤더는 http 메시지를 전송할때 필요한 부가 정보를 담는다. ex) 메시지 바디의 내용, 메시지 바디의 크기, 압충 방법, 인증 방법, 캐시 등등.. 표준으로 정해져있는 헤더는 매우 많고 필요할 경우 임의의 헤더도 추가 가능하다.

http 표준 (RFC7230)

 가장 최신 http 표준 스펙에서는 헤더를 표현 헤더, 메시지 바디를 표현 데이터라고 부른다. 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공해준다. 위의 그림을 표현 메타데이터와 페이로드 메시지로 구분한다. 메타 데이터는 데이터에 대한 데이터다. 전송하려는 데이터에 대한 정보라고 생각하면된다. => 헤더,  페이로드 메시지는 전송하고 싶은 데이터 그 자체이다 => 표현 데이터. 

 

 표현 헤더

표현 헤더는 전송, 응답 메시지에서 모두 사용한다.

• Content-Type - 표현 데이터가 JSON, HTML, XML 등등 미디어 타입과 문자 인코딩 방식을 설명한다
• Content-Encoding -표현 데이터를 압축해서 보낼 때 사용한다. 데이터를 전달하는 쪽에서 압축 방식을 보내면 읽는 쪽에서 이를 이용하여 압축을 해제한다.
• Content-Language - 표현 데이터의 언어를 표현한다. ( 뒤에 나오는 협상 헤더에서 사용된다.)
• Content-Length - 메시지 바디에 있는 데이터의 바이트 단위를 설명한다. 분할하는 등 변형된 데이터를 보낼 때는 사용하면 안된다.

 협상 헤더 (Contents Negotiation)

 요청 메시지에만 사용되며 클라이언트가 선호하는 표현을 요청한다.

• Accept - 클라가 선호하는 미디어 타입 전달
• Accept-Charset - 클라가 선호하는 문자 인코딩
• Accept-Encoding - 클라가 선호하는 압축 인코딩
• Accept-Language - 클라가 선호나는 언어

 4개 모두 종류만 다르고 비슷한 방식으로 작동한다. Accept-Language로  설명을 하면 서버에서 제공하는 언어가 여러 개 세팅되어있다.

 영어, 중국어, 한국어, 프랑스어가 서버에서 제공 가능하다하면 클라이언트의 ip에 따라서 요청하는 언어가 다르다. 이때 서버가 정확히 몇개의 언어를 제공가능한지 알 수 없다. 그래서 클라이언트에서는 여러 개의 후보를 우선 순위를 부여하여 요청한다. 우선 순위를 부여하는 방법은 Quality Values(q)를 사용한다.   Accept-Language: ko;q=0.9,en-us;q=0.8 숫자가 높을 수록 우선 순위가 높은 것이고 숫자가 생략 되어있는것은 1을 의미해서 제일 높은 우선 순위를 갖는다. 근데 클라이언트가 요청한 언어가 서버에서 제공하지 않으면? 어쩔 수 없다 그냥 서버에서 최우선으로 세팅 되어있는 언어로 데이터가 전송된다. Encoding, Charset 모두 동일한 메커니즘으로 작동한다.

 

 전송 방식

여러 전송 방식마다 추가해줘야하는 헤더들이 존재한다.

• Content-Length - 단순 전송에서 사용된다. 분할 등을 하지 않은, 컨텐츠에 대한 길이를 알 수 있을 때 사용한다.
• Content-Encoding - 압축 전송을 할 때 압축 방식을 나타낸다. 압축 전송을 하면 데이터 크기를 크게 줄여서 전송할 수 있다.
• Transfer-Encoding - 분할 전송을 할 때 사용하며 분할 전송을 할 때는 Content-Length를 사용하면 안된다.
• Range, Content-Rage - 범위 전송을 할 때 사용한다. 예시로 중간에 오류가 나서 데이터가 전송 중 멈춘 경우 Range를 사용해서 여기서부터 여기까지 다시 보내줘라고 요청하면 응답 메시지에서 Content-Range에 여기서부터 여기까지 보냈어~라고 담아서 전송해준다.

 일반 정보

• From - 유저 에이전트의 이메일 정보를 담는다. 잘 사용하지 않아~
• Referer - 요청 메시지에서 사용하며 현재 페이지의 이전 웹 페이지 주소를 담는다. 유입 경로를 분석 가능하다. 원래 referrer가 맞는데 처음에 사용할 때 오타로 referer가 넘어갔다. 근데 모두가 그냥 사용해서 지금까지 referer로 사용 중 ㅋㅋ
• User-Agent - 요청 메시지에서 사용하며 유저의 애플리케이션 정보를 담는다. 통계 정보가 전송되며 브라우저에 장애가 발생했을 때 어느 브라우저인지 파악 가능해서 서버 입장에서 도움이 된다.
• Server - 응답 메시지에서 사용하며 응답하는 서버의 소프트웨어 정보를 담는다.
• Date - 응답 메시지에서 사용하며 해당 메시지가 발생한 날짜와 시간을 담는다.

 특별한 정보

• Host - 요청 메시지에서 사용하며 요청한 호스트의 정보를 담는다. 필수 헤더이다. 하나의 IP에 여러 도메인이 적용되어있는 경우가 있는데(IP 하나로 여러 어플리케이션을 운영하는 것이다.) 이때 어떤 어플리케이션에 접속해야할지 Host를 통해 알 수 있다.
• Location - 3XX 응답 결과가 나왔을 때 (리다이렉션이 필요한 경우 -> URL을 바꿔서 접속해야 하는 경우) 변경해야할 위치를 담고있다.
• Retry-After -서비스가 점검 중이거나 불능일 때 복구 되는 시간을 알려준다.

인증

• Authorization - 클라이언트 인증 정보를 서버에 전달한다. 인증 메커니즘마다 들어가야하는 벨류 값이 다 다르다.
• WWW-Authenticate - 리소스 접근 시 필요한 인증 방법을 정의해준다. 401 Unauthorized와 함께 사용된다. 접근을 했는데 문제가 있거나 인증이 제대로 되지 않은 경우 사용한다.

쿠키

쿠키는 웹사이트 접속시 접속자의 개인장치에 다운로드 되고 브라우저에 저장되는 작은 텍스트 파일이다. 쿠키는 왜 필요할까. HTTP 프로토콜은 무상태(Stateless) 프로토콜이다. 클라이언트와 서버가 요청 응답을 다 주고 받으면 연결을 끊어서 

그 전의 상태를 기억하지 못한다. 내가 로그인을 해도 웹 브라우저서 내 이름을 기억하지 못하는 것이다. 이때 내 이름을 쿠키에 저장하여 사용하게 한다. 

• Set-Cookie - 서버에서 클라이언트로 쿠키 전달(응답) 
• Cookie - 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

 위의 예시에 적용하면 Set-Cookie: user = 'te__ho'를 사용해서 이름을 저장하고 요청 메시지를 보낼 때 Cookie: user = te__ho를 사용하여 서버가 사용하게 만들 수 있다. 데이터를 보이게 주고 받기 때문에 너무 중요한 데이터들은 쿠키로 저장하지 않는다. 사용자 로그인 세션, 광고 정보 트래킹에 많이 사용된다. 쿠키는 생명주기에 따라 세션 쿠키, 영속 쿠키로 구분할 수 있다. 세션 쿠키는 브라우저 종료시 까지만 유지한다. 로그인했던 페이지 창을 닫고 다시 열면 로그인 다시 해야하는 이유이다. 영속 쿠키는 만료일을 설정하여 해당 날짜까지 쿠키를 유지한다. 설정 값들을 통해 쿠키 접근 범위와 보안 방식을 따로 설정해줄 수 있다.

 

https://inf.run/QTy9

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