2010-02-16 20 views
8

He puesto mi aplicación utilizando Cherrypy 3.1.2 detrás de Nginx configurado como un proxy inverso. Todo funciona bien para las solicitudes GET, pero todas las solicitudes POST devuelven HTTP 400 - encabezado mal formado.CherryPy detrás de Nginx reverse-proxy POST solicitudes corrompidas/truncadas

tracé en CherryPy código fuente WSGI-servidor para ver el código de petición de manejo, y se informó que si por GET pide a la primera línea de petición lee correctamente como por ejemplo:

GET /home HTTP/1.0 

para Publicar demanda es como :

<HTTP headers truncated at front> 

POST /home HTTP/1.0 

Así que en lugar de la solicitud correctamente formada contiene línea de petición/POST GET seguido de cabeceras HTTP, POST solicita mi solicitud recibe de Nginx:

  1. primeras líneas de cabecera HTTP truncados de principio por algún número de bytes
  2. Entonces una línea en blanco indicando cabeceras HTTP od extremo
  3. luego un "POST/home HTTP/1.0", que fue claramente espera como una primera línea de la solicitud
  4. EDITAR: Ese es el final de la solicitud, por lo que tampoco hay datos de cuerpo que deben seguir los encabezados HTTP POST.

Además, el número de bytes del truncamiento de p.1 parece depender de la cantidad de datos de POST que haya en un formulario, por ejemplo, cuantos más caracteres escriba en/campos de formulario de inicio, más caracteres en los encabezados HTTP son eliminados.

Al parecer, Nginx está de alguna manera corrompiendo el encabezado cuando lo pasa al servidor de subida (mi aplicación).
PERO: cuando solo hice una prueba, Nginx redirigió a algunos sitios web externos (usando también solicitudes POST): todo va bien.

Así que ahora estoy bastante atrapado.

Mi configuración es: Windows XP Prof, Python/2.5.1, CherryPy/3.1.2, Nginx/0.8.32
navegadores: Firefox 2.0, Internet Explorer 7.0
Mi aplicación (independiente correr) es generalmente de trabajo y probado bajo una serie de configuraciones.

utilizo configuración bastante básico Nginx como:

upstream backend { 
    server localhost:8088 weight=1; 
} 
server { 
    listen 80; 
    server_name localhost; 

    location/{ 
     #proxy_read_timeout 300; 

     proxy_pass http://backend; 
     #proxy_redirect default; 
    } 
} 

Aunque probado muchos otros ejemplos y configuraciones de PROXY_PASS encontrar en la red.

¿Alguna idea de dónde buscar el problema? Configuración Nginx, mi aplicación CherryPy o en otro lugar?

NUEVO: Me pareció que funciona correctamente, pero solo para las solicitudes POST que tienen una longitud de contenido de cuerpo cero (se hace un vacío sin ningún campo para probar eso).
Y verificó que el recuento de bytes truncado desde el inicio es igual a Content-length + algún pequeño número de const (probablemente 2).

+0

¿Sucede incluso con solicitudes únicas? Puede obtener problemas con keep-alives en varias solicitudes si lee el número incorrecto de bytes para el cuerpo de la solicitud, lo que puede suceder si algo a lo largo de la línea usa el modo de texto IO en lugar de binario en Windows (que cambia las secuencias CRLF a LF, lanzando el conteo de bytes 'Content-Length'). – bobince

+0

Sí, sucede incluso si esa es la primera solicitud después de reiniciar la aplicación y volver a cargar Nginx. –

Respuesta

1

puede probar los parámetros:

ignore_invalid_headers on; 
sendfile     on; 

en el bloque http ... También podría intentar deshabilitar los mensajes de actividad y asegurarse de que está el registro de acceso/errores de depurar.

Cuestiones relacionadas