CORS를 사용하는 REST 애플리케이션을 구축 중입니다. 모든 REST 호출은 다르며 preflight OPTIONS 호출을받는 데 상당한 오버 헤드가 있음을 발견했습니다. 동일한 도메인에 대한 후속 호출이 캐시 된 응답을 사용하도록 프리 플라이트 OPTIONS 결과를 캐시하고 적용하는 방법이 있습니까?
CORS를 사용하는 REST 애플리케이션을 구축 중입니다. 모든 REST 호출은 다르며 preflight OPTIONS 호출을받는 데 상당한 오버 헤드가 있음을 발견했습니다. 동일한 도메인에 대한 후속 호출이 캐시 된 응답을 사용하도록 프리 플라이트 OPTIONS 결과를 캐시하고 적용하는 방법이 있습니까?
답변:
프리 플라이트는 전체 도메인이 아닌 요청에만 적용 할 수 있습니다. 같은 질문을 메일 링리스트에 올렸는데 보안 문제가있었습니다. 다음은 전체 스레드입니다. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0228.html
실행 전 요청 수를 제한하려면 몇 가지 고려할 사항이 있습니다. 먼저 WebKit / Blink 기반 브라우저는 최대 프리 플라이트 캐시를 10 분으로 설정합니다.
https://github.com/WebKit/webkit/blob/master/Source/WebCore/loader/CrossOriginPreflightResultCache.cpp https://chromium.googlesource.com/chromium/blink/+/master/Source/core/loader/CrossOriginPreflightResultCache .cpp
(다른 브라우저에서도 이것이 사실인지 확실하지 않습니다). 따라서 항상 Access-Control-Max-Age 헤더를 설정해야하지만 최대 값은 10 분입니다.
다음으로 PUT / DELETE 요청에 대한 프리 플라이트를 피하는 것은 불가능합니다. 따라서 API를 업데이트 / 삭제하려면 10 분마다 최소 한 번의 프리 플라이트가 필요합니다.
GET / POST에서 가능한 경우 사용자 지정 헤더를 사용하지 마십시오. 이러한 헤더는 여전히 프리 플라이트를 트리거하기 때문입니다. API가 JSON을 반환하는 경우 'application / json'의 Content-Type도 프리 플라이트를 트리거합니다.
API가 얼마나 "휴식"인지 기꺼이 구부리고 싶다면 몇 가지 더 시도해 볼 수 있습니다. 하나는 'text / plain'과 같이 프리 플라이트가 필요없는 Content-Type을 사용하는 것입니다. 사용자 지정 헤더는 항상 프리 플라이트를 트리거하므로 사용자 지정 헤더가있는 경우 쿼리 매개 변수로 이동할 수 있습니다. 극단적 인 경우 모든 요청이 단일 엔드 포인트로 이루어지는 JSON-RPC와 같은 프로토콜을 사용할 수 있습니다.
솔직히 말해서 브라우저의 프리 플라이트 캐시 제한 10 분과 REST의 리소스 URL 때문에 프리 플라이트 캐시는 상당히 쓸모가 없습니다. 장기간 실행되는 앱 과정에서 프리 플라이트를 제한하기 위해 할 수있는 일은 거의 없습니다. CORS 사양의 작성자가 앞으로이 문제를 해결하기를 바랍니다.
Access-Control-Max-Age
이 존재하고 정확히 동일한 URL이 표시 되지 않는 한 OPTIONS 요청을 트리거합니다. 브라우저가 이전에 지정한 기간 내에 있고 Access-Control-Max-Age
문제의 브라우저가 값을 줄이지 않습니다 (Webkit, Firefox). 사용자 지정 헤더를 제거하고 URL로 이동하면 브라우저가 OPTIONS 요청을 보내지 않습니다. 승리!
xDomain을 사용해보십시오
angular 또는 jQuery를 사용하는 경우 설정하는 것이 매우 간단했습니다. 앱 서버에서 아래 링크의 도움말에 명시된대로 proxy.html을 추가하십시오. "클라이언트"와 비올라에 js 파일을 참조하는 태그를 추가하십시오. 더 이상 프리 플라이트가 아닙니다. 이것은 cors 검사가 필요하지 않도록 iframe으로 래핑됩니다.