Achievement Goal
- 쿠키의 작동 원리를 이해할 수 있다
- HTTP 헤더의 역할에 대해 이해할 수 있다.
- 표현, 콘텐츠 협상 등 다양한 헤더의 역할에 대해 알 수 있다.
- REST API에 대해 이해할 수 있다.
- REST API 문서를 읽을 수 있다.
- REST API에 맞춰 디자인할 수 있다.
- HTTPS의 개념을 이해할 수 있다.
- HTTP와 HTTPS의 차이점을 이해할 수 있다.
< Cookie >
- 서버에서 클라이언트에 데이터를 저장하는 방법의 하나
- 서버가 원한다면 클라이언트에서 쿠키를 이용하여 데이터를 가져올 수 있음
- 서버 > 클라이언트, 클라이언트 > 서버 둘 다 포함
< 서버가 클라이언트에 데이터를 저장할 수 있습니다 >
- 아무 때나 데이터를 가져올 수 없음
- 데이터를 저장한 이후 특정 조건을이 만족하는 경우에만 다시 가져올 수 있음(쿠키 옵션으로 표현 가능)
1. Domain
- 서버에 접속할 수 있는 이름 (like www.google.com)
- 쿠키 옵션에서 도메인은 포트, 서브 도메인 정보(
www), 세부 경로를 포함하지 않음 - 쿠키 옵션에 도메인 정보가 존재한다면 클라이언트에서는 쿠키의 도메인 옵션, 서버의 도메인이 일치 해야만 쿠키 전송 가능
서버와 요청의 도메인이 일치하는 경우 쿠키 전송
2. path
- 서버가 라우팅할 때 사용하는 경로
- http://www.localhost.com:3000/users/login
Path = /users, 세부경로 = /login - 설전된 Path를 전부 만족하는 경우 요청하는 Path가 추가로 더 존재하더라도 쿠키를 서버에 전송할 수 있음
서버의 요청의 세부 경로가 일치하는 경우 쿠키 전송
3. MaxAge or Expires
- 쿠키가 유효한 기간을 정하는 옵션
- Expires는 클라이언트의 시간을 기준으로 언제까지 유효한지 Date를 지정
- 날짜를 초과하면 자동 파괴
- 두 옵션이 지정되지 않은 경우 탭을 닫아야만 쿠키 제거 가능
쿠키의 유효기간 설정
4. Secure
- 쿠키를 전송해야 할 때 사용하는 프로토콜에 따른 쿠키 전송 여부를 결정
HTTPS 에서만 쿠키 전송 여부 설정
5. HttpOnly
- 자바스크립트에서 브라우저의 쿠키에 접근 여부를 결정
- 옵션 true = 접근 불가 / 옵션 false = 접근 가능
- 옵션이 false인 경우 XSS공격에 취약
스크립트의 쿠키 접근 가능 여부 설정
6. SameSite
- Cross-Origin 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션의 조합으로 서버의 쿠키 전송 여부를 결정
- Lax :Cross-Origin 요청이면 'GET' 메소드에 대해서만 쿠키를 전송
- Strict : Cross-Origin이 아닌 same-site(같은 도메인) 인 경우에만 쿠키를 전송
- None: 항상 쿠키를 보내줄 수 있음. 다만 쿠키 옵션 중 Secure 옵션이 필요
- 옵션 지정 후 서버에서 클라이언트로 쿠키를 처음 전송하면 헤더에 Set-Cookie 라는 프로퍼티에 쿠키를 담아 전송
- 이후 클라이언트나 서버에서 쿠키를 전송해야 한다면 클라이언트는 헤더에 Cookie라는 프로퍼티에 쿠키를 담아 서버에 전송
같은 사이트에서만 쿠키를 사용할 수 있게 하는 설정
< 쿠키를 이용한 상태 유지 >
- 쿠키의 특성을 이용하여 Statelee한 인터넷 연결을 Stateful하게 유지할 수 있음
- 하지만 쿠키는 오랜 시간 동안 유지될 수 있고, 자바스크립트를 이용해 접근할 수 있기 때문에 민감한 정보를 담는 것은 위험함
HTTP 주요 헤더
< 요청(Request)에서 사용되는 헤더) >
From: 유저 에이전트의 이메일 정보
- 일반적으로 잘 사용하지 않음
- 검색 엔진에서 주로 사용
- 요청에서 사용
Referer: 이전 웹 페이지 주소
- 현재 요청된 페이지의 이전 웹 페이지 주소
- A → B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청
Referer를 사용하면 유입경로 수집 가능- 요청에서 사용
- referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐
User-Agent: 유저 에이전트 애플리케이션 정보
- 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
- 통계 정보
- 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
요청에서 사용 - e.g.
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36
Host: 요청한 호스트 정보(도메인)
- 요청에서 사용
- 필수 헤더
- 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
- 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용
Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄
- 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생
- 응답 헤더의 Access-Control-Allow-Origin와 관련
Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더
- “토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
- e.g.
- Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
< 응답(Response)에서 사용되는 헤더 >
Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
- 응답에서 사용
- e.g.
- Server: Apache/2.2.22 (Debian)
- Server: nginx
Date: 메시지가 발생한 날짜와 시간
- 응답에서 사용
- e.g.
- Date: Tue, 15 Nov 1994 08:12:31 GMT
Location: 페이지 리디렉션
- 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
- 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
- 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
Allow: 허용 가능한 HTTP 메서드
- 405(Method Not Allowed)에서 응답에 포함
- e.g.
- Allow: GET, HEAD, PUT
Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
- 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
- e.g.
- Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
- Retry-After: 120(초 단위 표기)
표현 헤더(Representation Headers)
HTTP 헤더와 바디
HTTP 헤더
표현 헤더
Content-Type
Content-Encodiong
Content-Language
Content-Length
콘텐츠 협상 헤더
콘텐츠 협상
잘 설계된 HTTP API(REST API)
REST API란?
- 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식
좋은 REST API를 디자인 하는 방법
- 사실상 2단계까지만 적용해도 좋은 API 디자인이라고 볼 수 있음, 이 경우 HTTP API라고도 부름
REST 성숙도 모델 - 0단계
- 단순히 HTTP 프로토콜을 사용하기만 해도 됨
- 좋은 REST API를 작성하기 위한 기본 단계
- RESTful 아키텍처 스타일을 따르지 않음
- 모든 API호출이 하나의 엔드포인트에 집중, 각 요청에 대한 HTTP 메서드가 적절게 사용되지 않을 수 있음
REST 성숙도 모델 - 1단계
- 개별 리소스와의 통신을 준수해야 함
- 개별 리소스에 맞는 엔드포인트를 사용해야 하고 요청하고 받은 자원에 대한 정보를 응담으로 전달해야 함
- RESTful 아키텍처 스타일을 따르기 시작함
- 각 리소스가 고유한 URI를 가짐
- HTTP 메서드가 적절하게 사용됨
- 각 리소스에 대해 일괄된 URI 규칙이 없음
REST 성숙도 모델 - 2단계
- CRUD에 맞게 적절한 HTTP 메소드를 사용하는 것에 중점
- 각 리소스에 일관된 URI규칙이 적용
- HTTP 상태 코드도 적절하게 사용
REST 성숙도 모델 - 3단계
- 응답에 리소스의 URI를 포함한 링크 요소를 삽입하여 작성
- 새로운 기능에 접근할 수 있도록 하는 것
첫 번재 발표
- 스크린샷을 보고, HTTP의 구조, 요청과 응답, 헤더 등 유추할 수 있는 내용을 모두 작성하세요.
css, js를 분리해서 사용중이다
Request URL : https://toss.im/ = 클라이언트가 서버로 보내는 요청의 URL
Request Method : GET = 리소스 조회
status Code : 200 OK = 성공
Remote Address : 211.115.96.201:443 = HTTPS 사용해 보안 연결한 클라이언트의 IP주소
Referrer Policy : ( strict-origin-when-cross-origin ) = 이전 페이지가 동일한 출처인 경우에만 Referer 헤더를 보내고 다른 출처로 이동하느 경우에는 생략
Response Headers
Connection: keep-alive = HTTP 연결을 계속 유지할 것
content-encoding: gzip = 응답 본문을 gzip 압축 형식으로 인코딩해서 보냈다는 것
Content-Type: text/html; charset=utf-8 = 본문의 데이터 형식이 텍스트, 문자 인코딩은 UTF-8
Date: Thu, 27 Jan 2022 03:17:53 GMT = 응답이 생성된 시각
Keep-Alive: timeout=60 = HTTP 연결이 유지되는 시간을 60초로 지정
key-event-id: AVTEXGMPJ6 = 통신에서 사용되는 이벤트 ID
Server: nginx = Nginx 웹 서버 소프트웨어를 사용하고 있음
Transfer-Encoding: chunked = 본문이 청크로 분할되어 전송될 것
vary: Origin,Access-Control-Request-Method,Access-Control-Request-Headers = 헤더의 필드 값이 변경되어 요청할 경우 응답이 달라질 수 있음
x-envoy-upstream-service-time: 8 = 서버가 처리하는데 8밀리초 걸림
X-Frame-Options: SAMEORIGIN = iframe으로 표시하는 것을 허용하지 않음
x-toss-event-id: AVTEXGMPJ6 = 통신에서 사용되는 이벤트 ID
Request Headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7 = 적힌 미디어 타입을 받아들일 수 있다
Accept-Encoding: gzip, deflate, br = gzip, deflate, br 인코딩 방식을 받아들일 수 있다
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7 = 한국어 영어 순으로 우선순위
Cache-Control: no-cache = 응답이 캐시되지 않았다
Connection: keep-alive = HTTP 연결을 유지하고 있다
Cookie: (-------) = 다양한 쿠키들
Host: toss.im = 호스트의 이름
Pragma: no-cache = 요청 결과를 캐시에 저장하지 않는다
sec-ch-ua: (------) = 브라우저의 기능 수준을 서버가 파악하여 적절한 기능을 수행하고 있다
sec-ch-ua-mobile: ?0 = 모바일 기기에서 접속했다(???)
오늘도 쉽지 않았지만 최대한 시간 안에 이해하려고 노력했음
있다가 저녁 복습때 한번 더 보고 또 보고 또 보면 그래도 오늘 배운 헤더나 쿠키, API에 대해서 조금이나마 이해할 수 있을듯~
술 땡긴다
