CORS 처리 시 options는 왜 부르는거지?(Simple, Pre-flight)

 

 

 

이번에 별도 시스템을 개발하면서 다른 도메인으로 파일을 업로드 하는 서비스를 개발했다. 파일을 업로드 해야하기에 jsonp 방식을 이용하지 않고 multipart 방식의 업로드를 해서 CORS 처리를 받는 시스템쪽 헤더에 추가했다. 지금 생각해보니 jsonp로도 파일을 올릴수 있을거 같은데... 암튼

 

Access-Control-Allow-Origin: *

 

이렇게 검색하면 비슷한 자료가 많이 나올텐데 개발할 당시에는 아무 문제 없이 테스트가 되었고 서비스도 오픈을 했는데 동작이 안되는거다. 알고보니 특정 조건이 맞지 않는 경우 cors 처리 시에 예비요청(pre-flight)이라는 options 방식으로 request 이후에 다시 정상 request를 날린다고 한다.

 

즉 Cross-origin HTTP(s) 요청은 두가지 방식이 있는데 단순요청(simple request) 와 비 단순 요청 혹은 예비요청 ( pre-flight ) 정도로 알고 있으면 되겠다.

 

- 단순요청 ( simple reuqest )를 사용하는 경우

1) GET, HEAD, POST 요청

2) POST 요청인 경우 ORIGIN 헤더를 포함

3) 요청 페이로드 유형이 text/plain, multipart/form-data 또는 application/x-www-form-urlencoded 이어야 한다.

4) 요청에 사용자 헤더가 없어야 한다.

 

- 예비요청 ( pre-flight )을 사용하는 경우

1) PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH 방식을 사용하는 경우

2) 금지된 헤더 이름을 사용하는 경우- https://fetch.spec.whatwg.org/#forbidden-header-name

3) 페이로드 유형이 text/plain, multipart/form-data 또는 application/x-www-form-urlencoded 이 아닌 경우

4) 하나 이상의 이벤트 리스너가 XMLHttpRequestUpload에 등록되어있는 경우

5)

 

사실 지금도 pre-flight를 왜 하는지, 꼭 해야만 하는건지 이해를 할수가 없다. 보안측면이라고 얘기하는 사람도 있지만 맞지 않는 거 같다. 변경된 api에 대한 체크 정도라고 나와있는데 굳이 체크해야하는 이유는 알수 없다. GET, POST 만으로도 동일한 수준의 서비스를 만들어낼수 있는 점을 생각해보면 프리플라이트는 굳이 없어도 되는 브라우저 스펙이 아닐까 생각한다. 

 

이걸 찾아보게 된 이유는 웹 방화벽 때문이다. 실제 운영중인 사이트에는 기본적으로 options 메소드를 차단하고 있어 서비스를 런칭하고 나니 당연히 에러가 발생하였고 해당 정책을 cors를 이용하기 위해서 빼야한다고 한 상태다.

 

1번 서비스는 단순요청으로 처리되는데 , 2번 서비스가 프리플라이트를 사용한다. jquery의 동일한 ajax 함수를 통해 서비스를 타고 있는건데도 두개의 request가 하나는 simple-request, 하나는 pre-flight다. 신기하다. 아직도 분석중이며 분석이 된다면 포스팅으로 남겨놔야겠다.

 

CORS의 simple-reuqest,와 preflight-request 좋은걸 알았다.