HTTP 공통 헤더
요청과 응답에 모두 사용되는 헤더이다.
Date: Http Message가 생성된 시간
Connection:
Cache-Control
Content-Length: Body의 길이
Content-Type: 컨텐츠 타입(MIME)과 charset을 설정할 수 있음
Content-Language: 사용자의 언어
Content-Encoding: 컨텐츠 압축 방식
요청 헤더
Host: 도메인 네임 및 포트 정보
User-Agent: client OS and Browser 정보
Accept: 요청하는 컨텐츠 타입
Accept-Charset: utf-8
Accept-Language: ko, en-US
Accept-Encoding: br, gzip, deflate
Authorization: 인증 정보를 담는 부분(JWT나 bearer 토큰 등)
Origin: 시작점이 어디인지 나타내는 부분
Referer: 이전 페이지의 주소
응답 헤더
Access-Control-Allow-Origin
Allow: 허용되는 메소드를 알리기 위한 부분(예로 get은 지원하나 post를 지원하지 않는 서버에 post를 요청했을 때, get을 세팅하여 전달
Content-Disposition: 클라이언트에 response body를 어떻게 표시할지 나타내는 부분으로 inline의 경우 웹페이지 화면에 표시되고? attachment는 다운로드된다.
Location: 300번대 redirection이나 201 created가 응답일 때 다음 요청으로 전달할 url을 알려주는 부분
Content-Security-Policy: 다른 외부 파일을 불러오는 경우, 차단할 소스와 불러올 소스를 지정하는 부분
쿠키 & 캐시 전용 헤더
앱 자원을 효율적으로 사용하기 위해서는 캐싱이 중요함. 이미 받을 데이터를 다시받을 필요는 없기 때문이다.
서버로 부터 받은 데이터나 외부로 부터 받은 데이터를 재요청 없이도 브라우저에 저장된 응답을 사용할 수 있음(정적인 데이터에 사용하면 좋을 듯)
GET 요청에 대해서만 사용하며, 다른 부분에 대해서는 사용할 수는 있으나 사용하지 않음
헤더 정보를 알아보면 Cache-Control이라는 필드에 값 세팅에 따라 캐싱 하지 않음, 만료된 캐시에 대해서 요청, 캐시 유효시간 세팅 등이 가능하다
AGE라는 필드는 캐시의 생명이 얼마나 남았는지 초로 나타낸다.
Expires는 캐시가 언제 만료되는지 나타내고, ETag는 컨텐츠가 변경되었는지를 판단하는데 사용하는 필드이다. ETag 값이 변경되었다면 캐시를 삭제하고 다시받아오게됨
If-None-Match는 서버에서 ETag가 다를 경우에만 컨텐츠를 새로 내려달라는 것을 나타내는 필드이다.
If-None-Match에 Etag를 세팅해서 요청을하면 서버는 ETag를 확인하고 비교하여, 같다면 서버는 304 Not Modified를 응답해서 캐시를 그대로 사용하게 합니다.
쿠키
브라우저에 저장 가능한 데이터로 데이터를 임시로 보관하는데 사용한다.
Set-Cookie는 서버가 클라이언트에게 이런 정보를 저장하라고 알리기 위해 사용하는 필드이고, 더불어 쿠키의 만료시간, 남은 수명 등을 설정할 수 있다.
쿠키는 XSS 공격과 CSRF 공격 등에 취약하기 때문에 HttpOnly 옵션 켜두는 것과 쿠키를 사용하는 요청은 서버에서의 검증을 반드시 하는 것이 좋음
Cookie는 Set-Cookie와는 반대로 클라이언트가 서버에게 쿠키를 보낼 때 사용함. CSRF을 방지하기 위해 정상적으로 들어온 요청인지 검증해야함
https://www.zerocho.com/category/HTTP/post/5b3ba2d0b3dabd001b53b9db
Content-Type 관련하여
일반적으로 HTTP Request Body에는 클라이언트가 전송하려는 데이터를 넣을 수 있으며, Body 타입을 Header에 명시함으로써 서버가 알맞게 처리할 수 있다.
해당하는 헤더 필드는 Content-Type이며 컨텐츠의 타입(MIME)과 문자열 인코딩(utf-8 등등)을 명시할 수 있다.
따라서 이 필드에 MIME 타입 중 하나를 선택하여 전송하려는 Input Data의 타입을 명시할 수 있다.
MIME은 타입과 서브타입으로 구성되는데 자세한 MIME 타입에 대해선 아래 URL을 확인하면된다.
https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types
상황에 따라 Request에 여러 종류의 데이터를 한번에 전송해야 하는 경우가 있다.(input간에 Content-type이 다를 때)
이경우 한 바디에 여러 종류의 데이터를 넣어야 한다는 것인데 multipart 시리즈의 타입을 사용하면 됨(예) 사진 정보와 이미지 파일을 한번에 전송할 경우)
Content-type이 Multipart/form-data인 경우 Body에는 input 데이터를 구분하기 위한 boundary가 명시되게 되며 아래 그림과 같이 사용된다.
input Data의 마지막에 대한 식별은 boundary에 --가 추가로 붙어있는지에 대한 여부로 확인 가능하다.
문자열은 전송될 때 인코딩되어 전송되는데,
영문이나 특수문자에 ascii로 문자가 인코딩되며, 한글은 퍼센트 인코딩되어 문자로 표현되고 여기서 ascii로 인코딩되어 전송된다.
https://ghdwn0217.tistory.com/76
Rest API에 대해서
Representational state transfer API
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
CORS에 대해서
교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.
SOP(same origin policy) 같은 출처에 대한 리소스만 공유할 수있다는 정책
하지만 다른 출저의 리소스를 가져오는 일은 굉장히 자주일어나는 일이기에 몇 가지 예외 조항을 두고 이 조항에 해당하는 리소스 요청은 출처가 다르더라도 허용하기로 했는데, 이 SOP의 예외 조항이 CORS라고 함
우리가 다른 출처로 리소스를 요청한다면 SOP 정책을 위반한 것이 되고, 거기다가 SOP의 예외 조항인 CORS 정책까지 지키지 않는다면 아예 다른 출처의 리소스를 사용할 수 없게 되는 것이다.
같은 출처와 다른 출처의 구분
하는 방법은 스킴과 Host Port인데, 여기서 중요한 사실 한 가지는 이렇게 출처를 비교하는 로직이 서버에 구현된 스펙이 아니라 브라우저에 구현되어 있는 스펙이라고 한다.
먼저 브라우저가 요청을 보내고 응답이 왔을 때, 이를 비교하고 CORS 위반으로 응답을 버리는 게된다.
따라서 CORS는 브라우저의 구현 스펙에 포함되는 정책이기 때문에, 브라우저를 통하지 않고 서버 간 통신을 할 때는 이 정책이 적용되지 않는다.
또한 CORS 정책을 위반하는 리소스 요청 때문에 에러가 발생했다고 해도 서버 쪽 로그에는 정상적으로 응답을 했다는 로그만 남기 때문에, CORS가 돌아가는 방식을 정확히 모르면 에러 트레이싱에 난항을 겪을 수도 있다.
끝내주는 정리
https://evan-moon.github.io/2020/05/21/about-cors/
Post
- maxPostSize와 MaxParameterCount 세팅이 가능하며, 무한하다.
content-type
-
application/x-www-form-urlencoded
&로 구분된 Key-Value tuple로 인코딩 된 값임
일반적으로 사용하는 것 -
multipart/form-data
바이너리 데이터는 multipart/form-data를 이용해야함 -
text/plain
Content-Dispostion
accepted
Post와 Put 차이
- put은 멱등성을 가진다.
