Analisis contoh arahan add_header Nginx

Kata Pengantar

Seperti yang kita sedia maklum, fail konfigurasi nginx menetapkan pengepala respons dengan menggunakan arahan add_header.

Gunakan curl untuk menyemak maklumat tapak dan mendapati bahawa pengepala yang dikembalikan adalah berbeza daripada yang dijangkakan:

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
...

Tapak utama telah mengkonfigurasi pengepala seperti hsts dalam nginx.conf:

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";

Tetapi pengepala respons tidak mempunyai pengepala ini. Sebagai tambahan kepada pengepala biasa, terdapat hanya satu pengepala x-cache yang dikonfigurasikan di lokasi.

Tanggapan pertama ialah CDN menapis pengepala ini? Jadi saya mencari dokumentasi cloudflare dan tidak mendapati ia akan mengendalikannya. Kemudian saya memikirkannya, apakah yang dilakukan oleh CDN untuk menapis ini? Adakah anda kenyang selepas makan? Mereka tidak melakukan penapisan!

Masalah dipindahkan ke konfigurasi nginx. Buka Google dan cari "nginx location add_header", dan anda akan mendapati banyak kelemahan. Klik pada dokumen add_header di tapak web rasmi dan terdapat perihalan ini (maklumat lain telah ditinggalkan):

mungkin terdapat beberapa arahan add_header ini diwarisi dari peringkat sebelumnya jika dan hanya jika tiada arahan add_header ditakrifkan pada tahap semasa.

Perhatikan bahawa "arahan ini diwarisi daripada tahap sebelumnya jika dan hanya jika tiada arahan add_header ditakrifkan pada tahap semasa.". Iaitu: tetapan induk akan diwarisi hanya jika tiada arahan add_header dalam tahap semasa. Jadi soalan saya adalah jelas: terdapat add_header di lokasi, dan konfigurasi dalam nginx.conf dibuang.

Ini adalah tingkah laku nginx yang disengajakan, dan ia tidak boleh dikatakan sebagai pepijat atau perangkap. Tetapi jika anda memahami ayat ini dengan mendalam, anda akan menemui fenomena yang lebih menarik: hanya add_header yang terkini berfungsi. add_header boleh dikonfigurasikan dalam http, pelayan dan lokasi, tetapi konfigurasi terdekat akan berkuat kuasa dan semua konfigurasi di atas akan menjadi tidak sah.

Tetapi masalahnya tidak berhenti di situ. Jika lokasi ditulis semula ke lokasi lain, hanya pengepala kedua akan muncul dalam hasil akhir. Contohnya:

location /foo1 {
 add_header foo1 1;
 rewrite / /foo2;
}

location /foo2 {
 add_header foo2 1;
 return 200 "ok";
}

Tidak kira meminta /foo1 atau /foo2, pengepala akhir hanyalah foo2:

Walaupun masuk akal bahawa ini adalah tingkah laku biasa , ia sentiasa membuatkan orang berasa tidak selesa Ia berasa agak terpaksa dan tidak selesa: pelayan kehilangan konfigurasi http, dan lokasi kehilangan konfigurasi pelayan, tetapi kedua-dua lokasi berada pada tahap yang sama!

Anda tidak boleh mewarisi konfigurasi induk dan anda tidak mahu mengulangi arahan dalam blok semasa Penyelesaiannya boleh menggunakan arahan sertakan.

Atas ialah kandungan terperinci Analisis contoh arahan add_header Nginx. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!