머리말
우리 모두 알고 있듯이 nginx 구성 파일은 add_header 지시문을 사용하여 응답 헤더를 설정합니다.
curl을 사용하여 사이트 정보를 확인했는데 반환된 헤더가 예상한 것과 다른 것을 발견했습니다.
http/2 200 date: thu, 07 feb 2019 04:26:38 gmt content-type: text/html; charset=utf-8 vary: accept-encoding, cookie cache-control: max-age=3, must-revalidate last-modified: thu, 07 feb 2019 03:54:54 gmt x-cache: miss server: cloudflare ...
기본 사이트는 nginx.conf에 hsts 및 기타 헤더를 구성했습니다.
add_header strict-transport-security "max-age=63072000; preload"; add_header x-frame-options sameorigin; add_header x-content-type-options nosniff; add_header x-xss-protection "1; mode=block";
하지만 응답 헤더는 그렇지 않습니다. 이러한 헤더가 없습니다. 일반 헤더 외에도 해당 위치에는 헤더 x-cache가 하나만 구성되어 있습니다.
첫인상은 CDN이 이러한 헤더를 필터링한다는 것인가요? 그래서 cloudflare의 문서를 찾아봤지만 이 문서를 처리할 수 있다는 것을 찾지 못했습니다. 그러다가 CDN이 이것을 필터링하기 위해 무엇을 하는지 생각했습니다. 먹고 나면 배가 부르나요? 그들은 검열 같은 일을 하지 않아요!
문제는 nginx 구성으로 이동합니다. Google을 열고 "nginx location add_header"를 검색하면 많은 결함을 찾을 수 있습니다. 공식 웹사이트에서 add_header 문서를 클릭하면 다음 설명이 있습니다(다른 정보는 생략되었습니다):
이러한 add_header 지시문은 정의된 add_header 지시문이 없는 경우에만 이전 수준에서 상속됩니다. 현재 수준에서 .
주의는 "이러한 지시문은 현재 수준에 정의된 add_header 지시문이 없는 경우에만 이전 수준에서 상속됩니다."에 초점을 맞춥니다. 즉, 현재 수준에 add_header 지시문이 없는 경우에만 상위 설정이 상속됩니다. 따라서 내 질문은 분명합니다. 위치에 add_header가 있고 nginx.conf의 구성이 삭제됩니다.
이것은 nginx의 의도적인 동작으로 버그나 함정이라고 할 수 없습니다. 하지만 이 문장을 깊이 이해한다면 더욱 흥미로운 현상을 발견하게 될 것입니다: 최신 add_header만 작동한다는 것입니다. add_header는 http, 서버 및 위치에서 구성할 수 있지만 가장 가까운 구성이 적용되며 위의 모든 구성은 유효하지 않습니다.
하지만 문제는 여기서 끝나지 않습니다. 위치를 다른 위치에 다시 쓰면 최종 결과에는 두 번째 헤더만 나타납니다. 예:
location /foo1 { add_header foo1 1; rewrite / /foo2; } location /foo2 { add_header foo2 1; return 200 "ok"; }
/foo1 또는 /foo2 요청에 관계없이 최종 헤더는 foo2뿐입니다.
이것이 정상적인 동작이라는 것은 이해가 되지만 항상 약간 강요되고 불편한 느낌이 듭니다. http 구성 및 위치가 손실되었습니다. 서버 구성은 양호하지만 두 위치가 동일한 수준입니다!
부모 구성을 상속받을 수 없으며 현재 블록에서 명령어를 반복하고 싶지 않은 경우 해결 방법은 포함 명령어를 사용하는 것입니다.
위 내용은 Nginx add_header 명령 예제 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!