nginx 設定チュートリアルにおける add_header の落とし穴の詳細な説明

序文

add_header は、headers モジュールで定義されたディレクティブです。名前が示すように、http 応答ヘッダーを追加するために使用されます。ただし、これは単に「追加」されただけであり、書き直されたわけではないことに注意してください。したがって、ヘッダーがすでに存在する場合、add_header を使用すると問題が発生します。さらに、nginx の以前のバージョンでは、add_header はエラー ページでの使用をサポートしていません。

これは多くの落とし穴があるコマンドです。処理段階は location 処理より後になります。location に書き込むことはできますが、別の location を書き換えると、前の location で処理されなかった add_header は失われます。例えば：

場所 = /a {
 add_headerに1を追加します。
 //b を書き換えます。
}
場所 = /b {
 ヘッダーを追加します b 2;
 204を返します。
} 

頭に1はないですよね？これは落とし穴だ！

もう 1 つの落とし穴は、冒頭で述べた重複の問題です。たとえば、コンテンツに Content-Type を設定したいのですが、default_type がグローバルに設定されているため、重複してしまいます。

デフォルトタイプ 'text/plain';

場所 = /a {
 ヘッダーコンテンツタイプ application/json を追加します。
 200 '"OK"' を返します。
} 

もちろん、この場所の default_type を空のままにしたり、add_header を使用せずにこの場所の default_type を直接変更するなど、多くの解決策があります。

最後の大きな落とし穴は、エラー ページでは機能しないことですが、これもドキュメントで明確に定義されています。たとえば、次の例をご覧ください。

場所 = /a {
 ヘッダーコンテンツタイプ application/json を追加します。
 404 '"見つかりません"' を返します。
}

JSONで応答したいのですが、ステータスコードが404なので、ここでのadd_headerは効果がありません。

この例では default_type の問題を解決できますが、他のヘッダーの場合はどうなるでしょうか?たとえば、Access-Control-Allow-Origin では何をすればよいでしょうか?その場合、Lua またはその他のサードパーティ モジュールを使用する以外に解決策はありません。もちろん、nginx はこの問題を認識しているため、ドキュメントには、always と呼ばれるパラメータがバージョン 1.7.5 以降でサポートされていることも記載されています。 nginx 自体はこの問題を解決しますが、1.6.2 ベースの tengine では問題が発生します。

要約する

上記はこの記事の全内容です。この記事の内容が皆さんの勉強や仕事に一定の参考学習価値を持つことを願っています。ご質問があれば、メッセージを残してコミュニケーションしてください。123WORDPRESS.COM を応援していただきありがとうございます。