☰

NGINX 301 および 302 は小さな nginx ドキュメント本体を提供します。この動作を削除する方法はありますか?

tag-icon • tag-icon nginx redirect 301-redirect
NGINX 301 および 302 は小さな nginx ドキュメント本体を提供します。この動作を削除する方法はありますか?

nginx の内部 301 および 302 処理を使用すると、nginx は適切な Location: ... ヘッダーを含む小さなドキュメント本体を提供することがわかりました。

次のような内容です (HTML の場合): 301 リダイレクト - nginx。

上記の動作に応じて、content-type text/html および content-length ヘッダーも送信されます。

当社は 302 リダイレクトを多数実行し、301 リダイレクトもいくつか実行していますが、上記の動作は帯域幅の無駄遣いであると考えています。

この動作を無効にする方法はありますか?

頭に浮かんだアイデアの 1 つは、error_page 301 302 を空のテキスト ファイルに設定することでした。まだテストしていませんが、上記の場合でも、content-type および content-length (0) ヘッダーが送信されると想定しています。

では、nginx で「本文なし」の 301/302 リダイレクトを送信するクリーンな方法はあるのでしょうか?

答え1

あなたが何を求めているのかを慎重に考え、真剣に検討してくださいそれをしない。

RFC 2616削除するエンティティ本体が存在することを指定します。

10.3.2 301 永久に移動

新しい永続的な URI は、応答の Location フィールドによって指定される必要があります。要求メソッドが HEAD でない限り、応答のエンティティには、新しい URI へのハイパーリンクを含む短いハイパーテキスト ノートが含まれている必要があります。

そして...

10.3.3 302 見つかりました

一時的な URI は、応答の Location フィールドで指定する必要があります。要求メソッドが HEAD でない限り、応答のエンティティには、新しい URI へのハイパーリンクを含む短いハイパーテキスト ノートが含まれている必要があります。

この文脈におけるSHOULDは次のように定義される。RFC 2119:

この単語、または形容詞「推奨」は、特定の状況では特定の項目を無視する正当な理由が存在する可能性があるが、別の方法を選択する前にその意味を完全に理解し、慎重に検討する必要があることを意味します。

RFC に違反することなくこれを行うことができますが、その完全な影響について認識しておく必要があります。

  • 実質的にメリットがないのに、多くの作業を行っています。エンティティ本体を無効にする唯一の論理的な理由は、帯域幅のコストを節約することです。これは確かにあなたが述べた理由ですが、違いは非常に小さいため、帯域幅のグラフで違いがわかる可能性は低いです。
  • ごく一部の Web クライアントは、3xx リダイレクトに自動的に従いません。RFC が書かれた当時は、この割合がはるかに大きかったため、そもそもこのリダイレクトが存在していましたが、暗い寝室やデータ センターのクローゼットの影には、いまだに古代の怪物が潜んでおり、時々姿を現します。最もよく見かけるのはcurl、今でも一般的に使用されている です。

この勧告は、RFC7231 の翻訳、これは単に（301 と 302 の両方について）次のように述べているだけです。

サーバーの応答ペイロードには通常、新しい URI へのハイパーリンクを含む短いハイパーテキスト ノートが含まれます。

サーバーの応答ペイロードには通常、さまざまな URI へのハイパーリンクを含む短いハイパーテキスト ノートが含まれます。

答え2

はい、できます絶対にNGINX でやってみよう！

  • 例外ハンドラをインストールするだけです。error_page、必要な応答を後処理します。エラー ページが HTTP ステータス コードを変更しないように設定してください。たとえば、パラメータを使用しない=(または、必要なコードをハードコードするために使用しない) ようにします。

  • 必ずreturn[text]ではなく をオプションで設定できる戻りステータス コードを含む応答URL。

  • 特定default_typeの、ヘッダー""を削除するようですContent-Type

完全なコードはここにあります。GitHubでStackOverflow.cnst.nginx.confリポジトリ:

# cat sf.421976.301-302-redirect-w-no-http-body-text.nginx.conf | sed 's#^#\t#g'
server {
    listen 1976;
    error_page 301 302 @30x; # keep original HTTP status code w/o `=`
    location @30x {
        default_type ""; # will remove Content-Type completely
        # `300` is a filler: client will get the original HTTP status code
        return 300;
    }
    return 301 http://example.su/test;
}

正常に動作していることの確認は次のとおりです。

% curl -i localhost:1976 | sed 's#^#\t#g'
HTTP/1.1 301 Moved Permanently
Server: nginx/1.2.1
Date: Mon, 28 Aug 2017 22:02:41 GMT
Content-Length: 0
Connection: keep-alive
Location: http://example.su/test

%

ブラウザでも試してみましたが、問題なく動作しました。

PS別の選択肢としては、ソースコードを修正して、ngx_http_error_301_page他にも変数はありますが、なぜ難しい方法を選ぶのでしょうか?! ^_^

答え3

ちょっと見苦しいですが、301/302 リクエストをプロキシし、proxy_method を使用して GET を HEAD リクエストに変更することもできます。テストしていませんが、HEAD リクエストは、応答なしのヘッダーまたは (できれば) content-* ヘッダーのみを送信する必要があります。

http://wiki.nginx.org/NginxHttpProxyModule#プロキシメソッド

関連情報