비전공자의 전공자 따라잡기 - 네트워크, HTTP

캐시 신선도 검사

캐시 신선도 검사

실제 데이터가 언제 바뀌었는지 데이터의 신선도를 보는데에 중요하다.

Last-Modified, ETag

언제 최종으로 생겼는지와 현재 버전을 알 수 있다.

캐시관련해서는 Last-Modified, ETag가 있는 경우가 많다.
이 둘 중에 하나만 있거나 둘 다 있거나 없다.
Last-Modified는 시간을 나타내고, ETag는 버전을 나타내준다.
내가 직접 버전을 알기쉽게 써도 되고 수정될 때마다 자동으로 바뀌게 해주는 것을 사용해도 좋다.

If-Match, if-None-Match

If-Match : ETag를 적어주면 서버에 있는 것과 똑같은 버전인지 확인하고 똑같은 데이터라면 서버가 캐시를 쓰라고 응답을 해준다. (다시 가져올 필요가 없기때문에 캐시를 사용)
if-None-Match : If-Match와 반대다. 서버와 ETag가 서로 다른 버전이라면 서버에서 데이터를 가져온다.

if-Modified-Since

Last-Modified와 짝이다.
만약, if-Modified-Since가 22년도라고 적혀있고 Last-Modified가 23년도라면
최신 데이터를 가지고 있는 캐시이기때문에 캐시 것을 가져와 쓰면 된다.
캐시 데이터와 서버 데이터의 시간이 서로 같은지 비교하는 방법이다.

if-Unmodified-Since

if-Modified-Since의 반대다.
if-Match로 Last-Modified와 ETag를 각각 비교해서 새로운 것을 쓸지 캐시를 쓸지 결정한다.
신선도 검사와 같이 수행된다.
if-Modified-Since와 if-Match가 전부 있다면 모두 만족해야 한다.

CORS

CORS요청과 에러

예시로 Naver에서 Facebook요청을 보내면 에러가 발생한다.
그 이유는 도메인(origin)이 다르기때문이다.

요청헤더에 access-control-allow-origin이라는 것의 값이 와일드카드(*) 라면 모든 사이트 접근 허용인 것이다. 사이트 이름이라면 그 사이트를 허용한다는 의미다.

프론트 개발자가 많이 겪는 에러다.
이유는 서버에서 access-control-allow-origin의 값을 적어서 전달을 하지만
브라우저가 access-control-allow-origin의 값이 있는지 확인하고 요청을 거부하는 것은 브라우저가 한다.
즉, 브라우저에서 서버로 요청을 보내면 에러가 발생할 수 있고 서버에서 서버로 요청을 보내면 발생하지 않는다.
access-control-allow-origin이 없으면 브라우저가 발생시키는 에러다.
서버에서는 응답을 보내줘도 브라우저가 에러를 발생시켜 데이터전달을 막는 것이다.

브라우저가 CORS 에러를 띄우는 이유

실수로 해커 사이트에 요청을 보내서 개인정보가 털리는 것을 막으려고 하는 것도 있다.
사실 해커가 만든 사이트라면 access-control-allow-origin을 이미 넣었을 것이다.
보안 문제의 이유 보다는 의도치 않았을 수 있는 데이터기때문에 브라우저가 막아뒀다고 보면 된다.

CORS에러가 나지 않는 브라우저가 있다.

Chrome이나 FireFox 등 승인되지 않은 변조된 브라우저는 CORS요청이 허용된다. (CORS에러 X)

CORS의 정확한 기준

다른 사이트로 요청을 보냈고 요청헤더에 access-control-allow-origin가 없는데도 CORS에러가 뜨지 않는 경우도 있다. 기준이 뭘까?

Simple Request : ‘access-control-allow-origin : *‘만 넣으면 허용이 된다.
Preflighted Request : Simple Request보다 복잡하다. 더 구체적으로 적어줘야 한다.
Same-origin-policy : “어떤 것이 같은 origin인가?”를 판단해놓은 것도 있다.
HTTP와 HTTPS도 나뉘고 포트도 나뉘는 식이다.다르면 다른 origin인 것이다.(MDN참고)

access-control-allow-credentials : true가 있어야 서로 다른 오리진의 요청이더라도 쿠키까지 가져올 수 있는 것을 허용할 수 있다.
CORS요청을 보내면서 쿠키까지 보내고 싶다면 사용한다.

CORS에러 해결 방법 - 에러나지 않게 하는 것

해결 : 브라우저 (CORS요청) » 같은 origin서버 » 다른 origon서버

서버에 access-control-allow-origin 헤더를 넣어달라고 요청을 하면 되지만…
관련된 것이 아니라면 해 줄리가 없다…

브라우저에서 같은 origin 서버로 보내고 그 데이터를 다른 origin 서버로 보내면 그것이 CORS에러가 나지 않는 해결책이다.
같은 origin서버를 프록시 서버라고 한다.
프록시 서버라고 하는 것은 꼭 그 의미가 아니지만, CORS를 해결하기 위해 같은 origin 서버를 거치는 것을 프록시라고 한다.
프록시 서버는 서버로 쓸 수 있는 게 없을 때 임시로 만든 서버(임시 서버 만들어 주는 webpack-dev-server)를 띄울 수 있게 해주는 기능이 프록시다.