Chapter Cookie
쿠키는 서버에서 클라이언트에 데이터를 저장하는 방법의 하나입니다. 클라이언트 <-> 서버
Domain
도메인은 서버에 접속할 수 있는 이름이며 쿠키 옵션에서 도메인은 포트 및 서버 도메인 정보, 세부 경로를 포함하지 않습니다. 쿠키 옵션에서 도메인 정보가 존재한다면 클라이언트에서 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키를 전송할 수 있습니다.
Path
세부 경로는 서버가 라우팅할 때 사용하는 경로입니다. 예 www. 뒤에 /user/login이 path 가 됩니다. Path 옵션의 특징은 설정된 path를 전부 만족하는 경우 요청하는 Path가 추가로 더 존재하더라도 쿠키를 서버에 전송할 수 있습니다.
MaxAge or Expires
쿠키가 유효한 기간을 정하는 옵션입니다.
- MaxAge는 앞으로 몇 초 동안 쿠키가 유호한지 설정하는 옵션입니다.
- Expires은 MaxAge와 비슷하지만 언제까지 유효한지 Date를 지정합니다
- 두 옵션이 지정되지 않는 경우에는 브라우저의 탭을 닫아야만 쿠키가 제거될 수 있습니다.
Secure
쿠키를 전송해야 할 때 사용하는 프로토콜에 따른 쿠키 전송 여부를 결정합니다.
HttpOnly
자바스크립트에서 브라우저의 쿠키에 접근 여부를 결정합니다. 만약 옵션이 True로 설정된 경우 자바스크립트에서는 쿠키에 접근이 불가합니다. 명시되는 않는 경우 기본으로 False으로 지정되며 자바스크립트에서 접근이 가능하고 XSS 공격에 취약합니다.
SameSite
Cross-Origin 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션의 조합으로 서버의 쿠키 전송 여부를 결정하게 됩니다.
- Lax :Cross-Origin 요청이면 'GET' 메소드에 대해서만 쿠키를 전송할 수 있습니다.
- Strict : Cross-Origin이 아닌 same-site 인 경우에만 쿠키를 전송 할 수 있습니다.
- None: 항상 쿠키를 보내줄 수 있습니다. 다만 쿠키 옵션 중 Secure 옵션이 필요합니다.
이때 'same-site'는 요청을 보낸 Origin과 서버의 도메인이 같은 경우를 말합니다.
다음 서버에서 클라이언트로 쿠키를 처음 전송하게 된다면 헤더에 Set-Cookie라는 프로퍼티에 쿠키를 담아 쿠키를 전송하게 됩니다.
HTTP 주요 헤더
요청 (request)에서 사용되는 헤더
From: 유저 에이전트의 이메일 정보
- 일반적으로 잘 사용하지 않음
- 검색 엔진에서 주로 사용
Referer: 이전 웹 페이지 주소
- 현재 요청된 페이지의 이전 웹 페이지 주소
- A → B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
- Referer 를 사용하면 유입경로 수집 가능
- referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐
User-Agent: 유저 에이전트 애플리케이션 정보
- 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
- 통계 정보
- 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
Host: 요청한 호스트 정보(도메인)
- 필수 헤더
- 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
- 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용
Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄
- 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
- 응답 헤더의 Access-Control-Allow-Origin와 관련
Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더
응답 (response)에서 사용되는 헤더
Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
Date: 메시지가 발생한 날짜와 시간
Location: 페이지 리디렉션
Allow: 허용 가능한 HTTP 메서드 (Allow GET, HEAD, PUT)
Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
표현 헤더
HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용합니다.
- Content-Type : 표현 데이터의 형식 -> 미디어 타입, 문자 인코딩 (Text/html; charest=utf-8)
- Content-Encoding: 표현 데이터의 압축 방식 -> (gzip, deflate, identity)
- Content-Language : 표현 데이터의 자연 언어 -> Ko, En, en-US etc
- Content-length: 표현 데이터의 길이 -> 바이트 단위
-> Transfer-Encoding 보다는 Content Encoding을 사용하며 Encoding 사용할 경우 chunked 방식 사용함 -> 요청 완료까지 데이터 양을 모를 경우 ‘chunked’으로 표시함
콘텐츠 협상 헤더
콘텐츠 협상 (Content negotiation)
- Accept : 클라이언트가 선호하는 미디어 타입 전달
- Accept-Charset : 클라이언트가 선호하는 문자 인코딩
- Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
- Accept-Language : 클라이언트가 선호하는 자연 언어 -> 서버에 원하는 단어 요청, 요청 단어가 없으면 기본 언어로 설정된 영어로 응답이 옵니다.
-> Language 운선순위를 지정할 수 있습니다. Quality Values(q) 값을 사용
-> accept-language : ko-KR,ko;q=0.9,en-US;q=0.8;en;q=0.7
-> 1순위를 한국어로 설정하였지만 서버가 한국어 지원하지 않을 경우 2위 영어로 응답
잘 설계된 HTTP API (Rest API)
웹 애플리케이션에서는 HTTP 메소드를 이용해 서버와 통신합니다. GET을 통해 웹 페이지나 데이터를 요청하고, POST로 새로운 글이나 데이터를 전송하거나 DELETE로 저장된 글이나 데이터를 삭제할 수 있습니다.
Rest API는 Representational State Transfer의 약자이며 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식을 말합니다.
좋은 REST API를 디자인 하는 방법
레오나르드 리차드슨은 REST API를 잘 적용하기 위한 4단계 모델을 만들었습니다.
0 단계
- 단순히 HTTP 프로토콜을 사용하기만 해도 됩니다. 단 API가 아니며 작성하기 위한 기본 단계입니다.
1 단계
1단계에서는 개별 리소스와의 통신을 준수해야 한다고 합니다. 모든 자원은 개별 리소스에 맞는 엔드포인트 (Endpoint)를 사용해야 한다는 것과 요청하고 받은 자원에 대한 정보를 응답으로 전달해야 한다는 것이 1 단계 입니다. 또한 실패 / 성공 리소스 여부를 포함한 응답도 포함 되어 합니다.
2단계
2단계에서는 CRUD에 맞게 적절한 HTTP 메소드를 사용하는 것에 중점을 둡니다. 조회(READ)하기 위해서는 GET 메소드를 사용하여 요청을 보내고, 이때 GET 메소드는 body를 가지지 않기 때문에 query parameter를 사용하여 필요한 리소스를 전달합니다. 응답 코드도 201 Created 로 명확하게 작성해야 하며, 관련 리소스를 클라이언트가 Location 헤더에 작성된 URI를 통해 확인할 수 있도록 해야, 완벽하게 REST 성숙도 모델의 2단계를 충족한 것이라고 볼 수 있습니다.
3 단계
HATEOAS(Hypertext As The Engine Of Application State)라는 약어로 표현되는 하이퍼미디어 컨트롤을 적용합니다. 응답에는 리소스의 URI를 포함한 링크 요소를 삽입하여 작성한다는 것이 다릅니다.
'HTTP' 카테고리의 다른 글
| DevOps Day 13 (3.23) HTTP_API 문서 작성 (0) | 2023.03.24 |
|---|
