본문 바로가기
개발자 일기/일일회고 (TIL)

부트캠프 36일차 (Web Server 기초)

by MS_developer 2022. 10. 13.

 

출처: 레딧

오늘의 생각

오늘도 웹 서버에 대해 조금 더 배울 수 있었다.

 

여전히 헷갈리는 부분이 많은 것 같다. CORS 에러가 발생했을 때 SOP에 문제가 있는지 처음 알게 되었다. 또한 CORS와 SOP의 정의를 배울 수 있어서 매우 유익했다. 항상 관련된 에러를 볼 때 구글링을 적당히 해서 문제를 해결하려고 했는데, 내가 해결하고도 해당 에러 메세지의 의미나 스택오버플로우에서 하는 설명을 잘 이해하지 못한 채 궁금증만 키워나간 상태였어서 다시 한 번 반성하기도 했다.

 

CORS 동작 방식, 특히 프리플라이트 요청Preflight Request을 사용하는 이유가 매우 흥미로웠다.

 

Node.js를 통한 CORS 설정 방법이나 문법은 다소 생소하지만, HTTP 트랜잭션 해부(Anatomy of an HTTP Transaction) 공식 가이드 문서가 매우 유용해서 열심히 정독하고 공부했다.

 

문서가 영어기 때문에 100% 이해했다고 자신할 수는 없지만, 무엇을 공부해야 하는지와 잘 모를 경우 살펴볼 문서가 있다는 사실이 든든했다. 

 

페어 프로젝트에서는 response.writeHead와 reponse.end를 두 번 사용하는 기초적인 실수를 했다.

 

찾는데 꽤 오래 걸렸는데, 이럴 때면 역시 기본기가...아쉽다.

 

그래도 네트워크에서도 보안 관련된 영역이라 흥미롭고 재밌게 코딩한 것 같다.

 


오늘의 키워드

동일 출처 정책SOP(Same-Origin Policy), 교차 출처 리소스 공유CORS(Cross-Origin Resource Sharing), 프리플라이트 요청Preflight Request, 단순 요청Simple Request, 인증정보를 포함한 요청Credentialed Request

 


오늘의 학습내용

  • 동일 출처 정책(SOP)의 정의와 사용하는 이유
  • 교차 출처 리소스 공유(CORS)의 정의와 사용하는 이유
  • CORS의 세 가지 동작 방식
  • CORS 설정 방법

 


어려웠던 keyword / 활용한 질문

 

Q. 위의 SOP 에러를 해결하기 위해서는 어떻게 해야 하나요?

 

A. 동일 출처 정책 SOP는 '같은 출처의 리소스만 공유가 가능하다'는 정책이기 때문에 교차 출처 리소스 공유 CORS를 사용해 다른 출처의 "선택한" 자원에 접근할 수 있는 권한을 부여해 브라우저에 알려줍니다. 

 

Q. 왜 '프리플라이트 요청은 요청을 두 번 보내기 때문에 리소스 측면에서 효율적이지 않다'는 말은 틀렸나요?

 

A. 프리플라이트 요청이 없는 서버에 요청을 보낼 경우 응답을 보내기 전에 해당 요청을 먼저 처리하게 되어 치명적인 서버 결함을 일으킬 수 있습니다. 브라우저는 응답을 받은 후 CORS 권한이 없다는 것을 인지하지만, 브라우저가 에러를 띄운 후에는 이미 요청이 수행된 상태가 되기 때문입니다.

 

댓글