7 votes

anonymous-one avatar

NGINX 301 et 302 servant de petit corps de document nginx. Y a-t-il un moyen de supprimer ce comportement ?

Demandé el 28 de Août, 2012
Quand la question a-t-elle été
9091 affichage
Nombre de visites la question a
3 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Nous avons remarqué que lors de l'utilisation du traitement interne 301 et 302 de nginx, nginx servira un petit corps de document avec l'en-tête approprié Location : ....

Quelque chose comme (en html) : 301 redirection - nginx.

Comme indiqué dans le comportement ci-dessus, un en-tête content-type text/html et content-length est également envoyé.

Nous faisons beaucoup de 302 et quelques 301 redirections, le comportement ci-dessus est une perte de bande passante à notre avis.

Est-il possible de désactiver ce comportement ?

Une idée qui nous a traversé l'esprit a été de définir error_page 301 302 dans un fichier texte vide. Nous ne l'avons pas encore testé, mais je suppose que même avec ce qui précède, les en-têtes content-type et content-length (0) seront envoyés.

Existe-t-il donc un moyen propre d'envoyer une redirection 301/302 "sans corps" avec nginx ?

Demandé el 28 de Août, 2012 par anonymous-one

Réponses

Trop de publicités?

10voto

Michael Hampton avatar
Michael Hampton Points 232226

Réfléchissez bien à ce que vous demandez, et envisagez sérieusement de ne pas le faire .

RFC 2616 spécifie que les corps d'entités à supprimer doivent être présents.

10.3.2 301 Déplacement permanent

Le nouvel URI permanent DEVRAIT être indiqué dans le champ "Location" de la réponse. Sauf si la méthode de requête était HEAD, l'entité de la réponse DEVRAIT contenir une courte note hypertexte avec un lien hypertexte vers le(s) nouvel(aux) URI.

et...

10.3.3 302 Found

L'URI temporaire doit être indiqué dans le champ "Location" de la réponse. Sauf si la méthode de requête était HEAD, l'entité de la réponse DEVRAIT contenir une courte note hypertexte avec un lien hypertexte vers le(s) nouvel(aux) URI.

Dans ce contexte, le terme SHOULD est défini dans le document RFC 2119 :

Ce mot, ou l'adjectif "RECOMMANDÉ", signifie qu'il peut y avoir des raisons valables, dans des circonstances particulières, d'ignorer un point particulier, mais qu'il faut en comprendre toutes les implications et les évaluer soigneusement avant de choisir une autre voie.

Vous pouvez maintenant le faire sans violer le RFC, mais vous devez être conscient de toutes les implications :

  • Vous faites beaucoup de travail pour pratiquement rien. La seule raison logique à laquelle je peux penser pour désactiver le corps de l'entité est d'économiser sur les coûts de la bande passante, et c'est en effet la raison que vous avez mentionnée, mais la différence est si minime qu'il est peu probable que vous voyiez une différence sur vos graphiques de bande passante.
  • Une infime partie des clients web ne suivent pas automatiquement les redirections 3xx. Cette fraction était beaucoup plus importante lorsque le RFC a été écrit, ce qui explique sa présence en premier lieu, mais il existe encore d'anciennes monstruosités tapies dans l'ombre des chambres sombres et des placards des centres de données, et elles sortent parfois pour jouer. Celle que vous êtes le plus susceptible de voir est curl qui est toujours d'usage courant.

Cette recommandation a été quelque peu assouplie avec RFC 7231 qui se contente de dire (pour 301 et 302) :

La réponse du serveur contient généralement une courte note hypertexte avec un lien vers le(s) nouvel(aux) URI.

La réponse du serveur contient généralement une courte note hypertexte avec un lien hypertexte vers les différents URI.

Répondu el 2 de Septembre, 2012 par Michael Hampton (232226 Points )

9voto

cnst avatar
cnst Points 12508

Oui, vous pouvez ABSOLUMENT le faire avec NGINX !

  • Il suffit d'installer un gestionnaire d'exception, alias error_page pour post-traiter les réponses demandées. Veillez à le définir de manière à empêcher la page d'erreur de modifier le code d'état HTTP, par exemple en n'utilisant pas l'option = (ou l'utiliser pour coder en dur le code que vous souhaitez).

  • Veillez à return une réponse avec un code d'état de retour qui vous permet de définir éventuellement l'option [text] et non le URL .

  • Préciser default_type de "" qui semble supprimer la Content-Type en-tête

Voici le code complet, également sur mon site web GitHub en StackOverflow.cnst.nginx.conf dépôt :

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

Voici la confirmation de son bon fonctionnement :

% 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

%

J'ai essayé dans les navigateurs, et cela a fonctionné correctement.

P.S. Une autre option serait de modifier le code source, et d'éditer le fichier ngx_http_error_301_page et autres variables, mais pourquoi choisir la voie la plus difficile ! ^_^

Répondu el 28 de Août, 2017 par cnst (12508 Points )

0voto

Jeffrey Hantin avatar
Jeffrey Hantin Points 189

C'est un peu moche, mais vous pourriez peut-être mettre en place un proxy pour les requêtes 301/302 et utiliser le proxy_method pour remplacer les requêtes GET par des requêtes HEAD. Je ne l'ai pas testé, mais les requêtes HEAD ne devraient envoyer que des en-têtes sans réponses ou (avec un peu de chance) des en-têtes content-*.

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

Répondu el 2 de Septembre, 2012 par Jeffrey Hantin (189 Points )

Questions connexes

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X