Responda con 200 desde la configuración de Nginx sin servir un archivo


122

He configurado Apache para enviar una respuesta 200 sin servir ningún archivo con esta línea de configuración

Redirect 200 /hello

¿Puedo hacer esto con Nginx? No quiero servir un archivo, solo quiero que el servidor responda con un 200 (solo estoy registrando la solicitud).

Sé que puedo agregar un archivo de índice y lograr lo mismo, pero hacerlo en la configuración significa que hay una cosa menos que puede salir mal.

Respuestas:


261

Sí tu puedes

location / {
    return 200 'gangnam style!';
    # because default content-type is application/octet-stream,
    # browser will offer to "save the file"...
    # if you want to see reply in browser, uncomment next line 
    # add_header Content-Type text/plain;
}

1
¿Cómo agrego una nueva línea a la respuesta? gangnam\nstyle?
tback

1
@tback, por supuesto, tienes razón
cadmi

44
add_header no funciona para mí, ya que agrega otro encabezado en lugar de reemplazar el antiguo 'Tipo de contenido'. En mi respuesta, tengo 2 encabezados 'Content-type': $ curl -v localhost / healthcheck / h1_pio> GET / healthcheck / h1_pio HTTP / 1.1> User-Agent: curl / 7.38.0> Host: localhost> Aceptar: / > <HTTP / 1.1 200 OK <Fecha: martes, 11 de octubre de 2016 13:27:53 GMT <Tipo de contenido: aplicación / flujo de octetos <Longitud de contenido: 25 <Conexión: mantener vivo <Tipo de contenido: aplicación / json
jmcollin92

1
@ jmcollin92 su comentario no tiene nada que ver con la pregunta que se le hizo y a la que se le dio la respuesta. porque obviamente tienes algún tipo de proxy_pass, fascgi_pass, lo que sea ... pero todavía respondo location / healthcheck / h1_pio {# proxy_pass blablabla lo que necesitas; proxy_hide_header Content-Type; add_header Content-Type application / json; } en el futuro, haga su pregunta correctamente y en la ubicación correcta
cadmi

66
@ jmcollin92 que puede suceder si tiene un default_type existente declarado en otro lugar. Puede anularlo usando default_type text/plain;dentro del bloque de ubicación en lugar de la add_headerdirectiva.
tjb1982

20

Es necesario usar un 204 ya que Nginx no permitirá un 200 sin cuerpo de respuesta. Para enviar un 204 sólo tiene que utilizar la directiva de retorno a return 204;la ubicación adecuada.


Si intenta ver esto a través de un navegador, parecerá que no hizo nada. Eso es intencional. No sirvió nada (204), no muestra nada. Para demostrar que sirvió un 204, use curl.
jnovack

4

Según las definiciones del código de estado, creo que quiere que sea un 204, y no 200. 200 debe estar con un recurso en la respuesta, o sospecho que la mayoría de los navegadores sanos se confundirían con esto. El otro que puede usar es 304, que es para contenido en caché.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html


Claro, que sea 204, ¿cómo lo hago? Aunque dudo mucho que un navegador esté confundido con un cuerpo vacío.
Theo

1
un cuerpo vacío sigue siendo una respuesta, con un objeto, como un index.html en blanco. Lo que solicitó es proporcionar una respuesta 200 sin recursos adjuntos (sin archivo servido). En cuanto a cómo hacerlo exactamente en nginx, necesito buscarlo yo mismo, solo he hecho esto una vez en Apache, y no puedo recordarlo.
Sandroid 01 de

304 parece que enviaría todas las señales incorrectas para cosas como depuración y devoluciones temporales.
Kzqai

2

Para completar la respuesta de @Martin Fjordval, tenga cuidado si está utilizando dicha configuración para realizar una comprobación de salud.

Si bien un 204código HTTP es semánticamente perfecto para una comprobación de estado (indicación de éxito sin contenido), algunos servicios no lo consideran un éxito.

A saber, tuve el problema con los equilibradores de carga de Google Cloud .

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.