개발일지 시작의
오늘 뭔가 살짝 정리가 된 기분!!
개발 업무내용
서버리스 백엔드2
오늘의 이슈/고민..그리고 해결한 내용
CORS는 세가지 동작 방식이 있는데 그중 Preflight Request에 대한 사진이다
프리플라이트(Preflight) 방식은 브라우저가 예비요청과 본 요청을 나누어 서버로 전송하는 것으로 이때 예비요청을 preflight라고 부르며 HTTP 메소드 중 OPTIONS 메소드가 사용된다.
브라우저가 서버에 예비 요청을 보내면 서버는 예비 요청에 대한 응답으로 현재 어떤 것들을 허용하고, 어떤 것들을 금지하고 있는지 응답 헤더에 정보를 담아 브라우저에 다시 보낸다. 응답 파기에 관한 결정은 브라우저에서 하기 때문에 서버에서 보낸 응답과 브라우저가 보낸 예비 요청을 비교한 후, 안전하다고 판단되면 다시 본 요청을 보낸다. 그래서 내가 delete를 할 때 첫번째 사진처럼 프리플라이트가 먼저가고 그 다음 본 요청 delete가 간다.
두번째 사진은 request의 응답에 사용되는 헤더에 포함되는 정보를 적어준건데 이게 바로 어떤 것을 금지하고 어떤 것을 허용하는지에 대한 것이다. origin을 "* = all"로 적어주는 것은 바람직하지 않지만 나는 일단 test해본 것이기 때문에 저렇게 했다.
세번째 사진은 브라우저가 보낸 요청인데 Origin에 대한 정보 뿐만 아니라 예비요청 이후 보낼 본 요청에 대한 정보도 포함되어 있다. 나는 origin을 전부 허용해줬지만 응답 헤더에 유효한 Access-Control-Allow-Origin 값의 존재 유무로 CORS 정책 위반인지 아닌지 확인할 수 있다. 예비 요청에 실패해서 status code가 200이 아니여도 헤더에 유효한 Access-Control-Allow-Origin 값이 들어가있다면 CORS 정책 위반이 아니다.
To-do List
서버리스 실습, 스프링 강의듣기
