NGINX, ssl, CORS 및 Access-Control-Allow-Origin 값의 캐싱이 교차 사이트

Question

http와 https에서 두 사이트를 처리하는 nginx 구성을 쓰려고하는데, 클라이언트는 두 사이트를 모두 방문하지 않지만 캐싱/사이트 간 문제가있는 경우 두 사이트를 방문합니다. 내가 example.com을로드하는 경우

# Allow cross origin 
location ~* \.(eot|svg|ttf|woff|woff2|json)$ { 
    if ($http_origin ~* (https?://(admin\.)?example\.com(:[0-9]+)?)) { 
     add_header 'Access-Control-Allow-Origin' "$http_origin"; 
    } 
} 

그래서, 모든 작동하지만 내가로드 할 때 다음 admin.example.com 나는이

(인덱스) 같은 문제를 얻을 : 1은 XMLHttpRequest http://origin.example.com/js/data-lib/currency.json를로드 할 수 없습니다. 'Access-Control-Allow-Origin'헤더의 값은 'http : // example'입니다. co.kr '은 공급 된 원점과 동일하지 않습니다. 오리진 'http : // admin. 예 . com '은 (는) 액세스가 허용되지 않습니다.

브라우저에서 브라우저의 원래 요청을 캐시했기 때문에 내가 말할 수있는 것만 큼 가까운 곳에서 서버의 다른 요청이 허용하더라도 브라우저가 원래의 요청을 캐시하고 캐시를 거부합니다. Chrome 개발자 도구에서 캐시 사용 중지를 선택하면 문제가 발생하지 않습니다.

이 문제를 어떻게 해결할 수 있습니까? 여러 도메인 + SSL/http 모두를 하나의 구성으로 할 수 있습니까? 아니면 도메인 및 프로토콜을 기반으로 요청을 분할 할 필요가 있습니까?

당신이해야 값 Origin으로 Vary 응답 헤더를 추가하는 경우

Answer 1

(내 예제에서 끔찍한 공간에 대한 죄송합니다, 분명히 StackOverflow의 내가 그냥 예를 쓰고 있어요 때 링크를 게시하려고 해요 생각) Origin 요청 헤더의 값이 캐시 된 요청의 값인 Origin 값과 다른 경우 브라우저가 캐시를 건너 뛰고 새 네트워크 요청을하게하는 효과가 있습니다.

최소한 브라우저의 효과는 the relevant part of the HTTP spec이어야합니다.

그래서 당신은이 일을 당신의 nginx의 설정을 업데이트 할 수 있습니다 : 당신은 the MDN article on the Vary response header에서 더 많은 읽을 수 있습니다

# Allow cross origin 
location ~* \.(eot|svg|ttf|woff|woff2|json)$ { 
    if ($http_origin ~* (https?://(admin\.)?example\.com(:[0-9]+)?)) { 
     add_header 'Access-Control-Allow-Origin' "$http_origin"; 
     add_header 'Vary' "Origin"; 
    } 
} 

.

Vary HTTP 응답 헤더는 캐시 된 응답이 원본 서버에서 새로운 하나를 요청 보다는 사용할 수 있는지 여부를 결정하는 미래의 요청을 헤더와 일치하는 방법을 결정합니다. 콘텐츠 협상 알고리즘에서 리소스 표현을 으로 선택할 때 사용 된 헤더를 표시하기 위해 서버에서 사용됩니다.