☰

NGINX 301 und 302 stellen einen kleinen Nginx-Dokumententext bereit. Gibt es eine Möglichkeit, dieses Verhalten zu entfernen?

tag-icon • tag-icon nginx redirect 301-redirect
NGINX 301 und 302 stellen einen kleinen Nginx-Dokumententext bereit. Gibt es eine Möglichkeit, dieses Verhalten zu entfernen?

Wir haben festgestellt, dass nginx bei Verwendung der internen 301- und 302-Verarbeitung von nginx einen kleinen Dokumenttext mit dem entsprechenden Location: ...-Header bereitstellt.

Etwas in der Art (in HTML): 301-Weiterleitung – nginx.

Entsprechend dem obigen Verhalten wird auch ein Header vom Inhaltstyp „Text/HTML“ und eine Headerlänge gesendet.

Wir führen viele 302- und einige 301-Weiterleitungen durch. Das oben beschriebene Verhalten ist unserer Meinung nach eine Verschwendung von Bandbreite.

Gibt es eine Möglichkeit, dieses Verhalten zu deaktivieren?

Eine Idee, die uns in den Sinn kam, war, error_page 301 302 auf eine leere Textdatei zu setzen. Wir haben das noch nicht getestet, aber ich gehe davon aus, dass auch mit dem oben genannten die Header „content-type“ und „content-length (0)“ gesendet werden.

Gibt es also eine saubere Möglichkeit, mit Nginx eine 301/302-Weiterleitung ohne Text zu senden?

Antwort1

Überlegen Sie genau, was Sie verlangen, und überlegen Sie gut,tue es nicht.

RFC 2616Gibt an, dass die zu entfernenden Entitätskörper vorhanden sein sollen.

10.3.2 301 Dauerhaft verschoben

Die neue permanente URI SOLLTE im Feld „Standort“ in der Antwort angegeben werden. Sofern die Anforderungsmethode nicht HEAD war, SOLLTE die Entität der Antwort eine kurze Hypertextnotiz mit einem Hyperlink zu den neuen URIs enthalten.

Und...

10.3.3 302 gefunden

Die temporäre URI SOLLTE im Feld „Standort“ in der Antwort angegeben werden. Sofern die Anforderungsmethode nicht HEAD war, SOLLTE die Entität der Antwort eine kurze Hypertextnotiz mit einem Hyperlink zu den neuen URIs enthalten.

SOLLTE ist in diesem Zusammenhang definiert inRFC 2119:

Dieses Wort oder das Adjektiv „EMPFOHLEN“ bedeutet, dass es unter bestimmten Umständen triftige Gründe geben kann, einen bestimmten Punkt zu ignorieren, dass man jedoch alle Auswirkungen verstehen und sorgfältig abwägen muss, bevor man sich für eine andere Vorgehensweise entscheidet.

Sie können dies zwar tun, ohne gegen die RFC zu verstoßen, Sie sollten sich jedoch über sämtliche Konsequenzen im Klaren sein:

  • Sie machen viel Arbeit und haben praktisch keinen Nutzen davon. Der einzige logische Grund, der mir einfällt, um den Entity Body zu deaktivieren, ist die Einsparung von Bandbreitenkosten. Tatsächlich ist dies der Grund, den Sie genannt haben, aber der Unterschied ist so minimal, dass Sie in Ihren Bandbreitendiagrammen wahrscheinlich überhaupt keinen Unterschied feststellen werden.
  • Ein sehr kleiner Teil der Webclients folgt 3xx-Weiterleitungen nicht automatisch. Dieser Anteil war viel größer, als das RFC geschrieben wurde, weshalb es überhaupt vorhanden ist, aber es gibt immer noch uralte Monstrositäten, die in den Schatten dunkler Schlafzimmer und Rechenzentrumsschränke lauern und manchmal zum Vorschein kommen. Am wahrscheinlichsten ist curl, das immer noch allgemein verwendet wird.

Diese Empfehlung wurde etwas gemildert durchRFC 7231, die lediglich besagt (für 301 und 302):

Die Antwortnutzlast des Servers enthält normalerweise eine kurze Hypertextnotiz mit einem Hyperlink zu den neuen URIs.

Die Antwortnutzlast des Servers enthält normalerweise eine kurze Hypertextnotiz mit einem Hyperlink zu den verschiedenen URIs.

Antwort2

Ja, du kannstABSOLUTmachen Sie es mit NGINX!

  • Installieren Sie einfach einen Ausnahmehandler, auch bekannt alserror_page, um erforderliche Antworten nachzubearbeiten. Stellen Sie sicher, dass Sie es so einstellen, dass die Fehlerseite den HTTP-Statuscode nicht ändert. Verwenden Sie den =Parameter beispielsweise nicht (oder verwenden Sie ihn, um den gewünschten Code fest zu codieren).

  • Stellen Sie sicher, dassreturneine Antwort mit einem Rückgabestatuscode, der es Ihnen ermöglicht, optional den festzulegen [text], nicht den URL.

  • Angebendefault_typevon , wodurch die Kopfzeile ""scheinbar entfernt wirdContent-Type

Hier ist der vollständige Code, auch bei mirGitHubInStackOverflow.cnst.nginx.confRepository:

# 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;
}

Hier ist die Bestätigung, dass es ordnungsgemäß funktioniert:

% 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

%

Ich habe es in den Browsern versucht und dort hat es auch problemlos funktioniert.

PS Eine andere Möglichkeit wäre, den Quellcode zu ändern und diengx_http_error_301_pageet al Variablen, aber warum den schwierigen Weg gehen?! ^_^

Antwort3

Es ist ein bisschen hässlich, aber vielleicht könnten Sie 301/302-Anfragen proxyen und die Proxy-Methode verwenden, um GET- in HEAD-Anfragen zu ändern. Ich habe es nicht getestet, aber Head-Anfragen sollten nur Header ohne Antworten oder (hoffentlich) Content-*-Header senden.

http://wiki.nginx.org/NginxHttpProxyModule#proxy_method

verwandte Informationen