☰

NGINX 301 y 302 que sirven cuerpos de documentos nginx pequeños. ¿Alguna forma de eliminar este comportamiento?

tag-icon • tag-icon nginx redirect 301-redirect
NGINX 301 y 302 que sirven cuerpos de documentos nginx pequeños. ¿Alguna forma de eliminar este comportamiento?

Hemos notado que cuando se utiliza el manejo interno 301 y 302 de nginx, nginx proporcionará un cuerpo de documento pequeño con el encabezado Ubicación apropiado: ....

Algo parecido a (en html): redirección 301 - nginx.

Según corresponda en el comportamiento anterior, también se envía un texto/html de tipo de contenido y un encabezado de longitud de contenido.

Hacemos muchas redirecciones 302 y algunas 301; en nuestra opinión, el comportamiento anterior es un desperdicio de ancho de banda.

¿Alguna forma de desactivar este comportamiento?

Una idea que se nos pasó por la cabeza fue configurar error_page 301 302 en un archivo de texto vacío. No hemos probado esto todavía, pero supongo que incluso con lo anterior, se enviarán los encabezados de tipo de contenido y longitud de contenido (0).

Entonces, ¿existe una manera limpia de enviar una redirección 301/302 "sin cuerpo" con nginx?

Respuesta1

Piensa muy detenidamente en lo que estás pidiendo y considera seriamenteno hacerlo.

RFC 2616especifica que los cuerpos de la entidad que desea eliminar deben estar presentes.

10.3.2 301 movido permanentemente

El nuevo URI permanente DEBE figurar en el campo Ubicación de la respuesta. A menos que el método de solicitud fuera HEAD, la entidad de la respuesta DEBE contener una breve nota de hipertexto con un hipervínculo a los nuevos URI.

y...

10.3.3 302 encontrado

El URI temporal DEBE ser proporcionado por el campo Ubicación en la respuesta. A menos que el método de solicitud fuera HEAD, la entidad de la respuesta DEBE contener una breve nota de hipertexto con un hipervínculo a los nuevos URI.

DEBE, en este contexto, se define enRFC 2119:

Esta palabra, o el adjetivo "RECOMENDADO", significa que pueden existir razones válidas en circunstancias particulares para ignorar un elemento en particular, pero se deben comprender todas las implicaciones y sopesar cuidadosamente antes de elegir un curso diferente.

Ahora puedes hacer esto sin violar el RFC, pero debes tener en cuenta todas las implicaciones:

  • Estás haciendo mucho trabajo sin prácticamente ningún beneficio. La única razón lógica que se me ocurre para deshabilitar el cuerpo de la entidad es ahorrar en costos de ancho de banda y, de hecho, esta es la razón que mencionaste, pero la diferencia es tan mínima que es poco probable que veas una diferencia en tus gráficos de ancho de banda.
  • Una fracción muy pequeña de los clientes web no sigue automáticamente los redireccionamientos 3xx. Esta fracción era mucho mayor cuando se escribió el RFC, razón por la cual está ahí en primer lugar, pero todavía hay monstruosidades antiguas acechando en las sombras de dormitorios oscuros y armarios de centros de datos, y a veces salen a jugar. El que es más probable que vea es curl, que todavía es de uso común.

Esta recomendación se ha relajado un poco conRFC 7231, que simplemente dice (tanto para 301 como para 302):

La carga útil de respuesta del servidor generalmente contiene una breve nota de hipertexto con un hipervínculo a los nuevos URI.

La carga útil de respuesta del servidor generalmente contiene una breve nota de hipertexto con un hipervínculo a los diferentes URI.

Respuesta2

Sí tu puedesABSOLUTAMENTE¡Hazlo con NGINX!

  • Simplemente instale un controlador de excepciones, también conocido comoerror_page, para posprocesar las respuestas requeridas. Asegúrese de configurarlo de tal manera que evite que la página de error modifique el código de estado HTTP; por ejemplo, no use el =parámetro (o utilícelo para codificar el código que desee).

  • Asegurate quereturnuna respuesta con un código de estado de retorno que le permite configurar opcionalmente el [text], no el URL.

  • Especificardefault_typeof "", que parece eliminar el Content-Typeencabezado

Aquí está el código completo, también en miGitHubenStackOverflow.cnst.nginx.confrepositorio:

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

Aquí está la confirmación de que funciona correctamente:

% 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

%

Lo probé en los navegadores y funcionó bien allí también.

PD: Otra opción sería modificar el código fuente y editar elngx_http_error_301_pageet al variables, pero ¿por qué tomar el camino difícil? ^_^

Respuesta3

Es un poco feo, pero tal vez puedas enviar solicitudes 301/302 y usar proxy_method para cambiar las solicitudes GET a HEAD. No lo he probado, pero las solicitudes de encabezado solo deben enviar encabezados sin respuestas o (con suerte) encabezados de contenido-*.

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

información relacionada