교차 출처 교차 출처 리소스 공유 관련 글을 보다가 어디서 Access-Control-Allow-Origin 말고도 Access-Control-Allow-Methods 라는 것도 무조건 추가하여 특정 http 메서드 사용 허용을 해줘야 한다고 봤다.
프록시 서버를 만들었을 때도 그렇고, CORS 오류를 해결하기 위해서는 이런 것 까지 신경 써본 경험이 없어서 express 서버 간단하게 만들어 테스트를 해봤는데, 있으나 없으나 무조건 응답이 잘온다.
없으면, 기본적으로 모든 요청 메서드를 허용해주나 싶어 DELETE만 남겼는데도, 응답이 잘온다.
구글에게 물어보니, 요청 메서드가 GET과 POST인 것들은 Access-Control-Allow-Methods가 없어도 정상적인 응답을 받는다고 한다.
바로 다른 메서드 요청 해보니, 오류가 나온다.
CORS 오류 요청에서는 실제로 어떤 요청 메소드를 썻는지 알려주지 않아 사진에서는 확인할 수 없지만, PUT 요청을 해본 것이다.
Access-Control-Allow-Methods에 PUT을 추가하니, 정상 응답을 받는다.
이 때 의심가는게 혹시 preflight 여부에 따라 Access-Control-Allow-Methods를 무시할 수 있는지 까지 생각할 수 있는데, 상관이 없다고 한다.
확인해보니, 정말로 preflight를 발생하는 POST 요청도 Access-Control-Allow-Methods내에 POST 메소드가 없어도 정상적인 응답을 받는다.
위의 테스트를 진행하던 도중, POST 요청에서 브라우저가 preflight를 보내게 하기 위해 Content-Type을 변경하여 요청했다.
그런데 CORS 오류가 나오길래, 검색 결과가 틀렸다고 생각했다.
알고보니, 응답 헤더 Access-Control-Allow-Headers 쪽에 Content-Type이 없었기 때문이었고, 이를 넣어주니 응답이 잘 온다.
추가적으로 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers를 추가, 삭제하며 테스트를 진행하면서 알게 된 것이 있다.
브라우저상에서 응답 헤더에 특정 값을 받는 요청을 한 번이라도 진행한 뒤, 백엔드에서 해당 헤더를 더 이상 제공해주지 않으면(CORS 오류를 발생시키기 위해 완전하게 제거하는 테스트를 진행했었다.), 브라우저 스스로 응답의 헤더에 기존에 있었던 값을 넣어서 받는다. 이는 꼭 헤더에 저 Access Control Allow 관련한 것들뿐만이 아니고 모든 헤더 내의 데이터가 그런 것을 확인했다.
다른 브라우저를 켜서 요청을 할 때는 당연히 백엔드에서 주지 않으니 당연히 오류가 나오는데, 기존에 정상 응답을 받았으면 계속해서 정상적인 응답을 받는다. 이는 새로고침을 해도, 강력 새로고침을 해도, 크롬 브라우저를 사용했는데 브라우저를 완전히 종료했다가 켜도 계속해서 정상 응답을 받는다.
크롬과 같은 일부 브라우저는 CORS관련 헤더를 위한 자체 캐시가 있으며, 이는 브라우저를 지운 후에도 유지될 수 있다고 한다.
해결하는 방법은 캐시 비우기 및 강력 새로고침을 해야 비로소 정상이 된다.
이 상황을 겪어보니, 실제 운영 환경에서 응답 헤더에 추가로 인해 오류가 발생하여 이를 서버에서 제거했을 때를 상상했다.
한 번이라도 브라우저에 접속한 사용자는 계속 그 헤더를 받을 수도 있다고 상상하니, 누구는 되고 누구는 안되는 상황이 나올 것이고, 개발자는 이 문제가 헤더 때문이라는 것을 알고 있지 않는다면, 분석해서 알아차리기는 정말 힘들 것 같다.