django - que - Cabeceras de respuesta truncadas o sobredimensionadas recibidas del proceso daemon
que es un request (4)
De repente tuve el mismo problema después de una actualización. La siguiente actualización solucionó el problema ... Ejecuté arch, a partir de la fecha de esta publicación, la versión de WSGI en repos funciona.
Hace poco migré una aplicación python django de un sistema Debian a una distribución empresarial redhat. La aplicación se aloja usando httpd, mod_wsgi y ejecutándose en un venv en un proceso de daemon. En solicitudes grandes ahora recibo el siguiente mensaje de error en el archivo de registro:
"Truncated or oversized response headers received from daemon process"
Nunca he experimentado algo como esto y Google no es la clave aquí también. Comprobé la configuración de apache, pero ninguna configuración está relacionada con los encabezados de respuesta allí.
Mi configuración httpd.conf se ve así (bastante estándar):
WSGIPassAuthorization On
WSGIScriptAlias / /var/www/myapp/wsgi.py
WSGIDaemonProcess my.name python-path=/path/to/myapp/:/path/to/venv/lib/python2.7/site-packages display-name=%{GROUP}
WSGIProcessGroup my.name
¿Algún gurú tiene una pista en qué dirección debería mirar?
El código usado por Apache por mod_wsgi aplica un límite en el tamaño de un único encabezado de respuesta devuelto por los procesos del modo daemon de mod_wsgi. Esto daría como resultado un mensaje de error críptico de Apache que no apuntaba en absoluto al problema. De memoria el error anterior fue:
Premature end of script headers
El límite de tamaño también estaba codificado en Apache y no se pudo cambiar. Esto ha causado problemas para algunas aplicaciones web de Python, como Keystone en OpenStack, que genera encabezados de autenticación muy grandes.
En mod_wsgi 4.1+, la dependencia del código Apache se ha eliminado y el límite ahora es configurable. El mensaje de error también es más específico como lo ha visto.
El tamaño de encabezado máximo predeterminado para lo que se devuelve desde el modo daemon mod_wsgi, que es el nombre y el valor del encabezado, es de aproximadamente 8192 bytes. Puede anular esto utilizando la opción ''header-buffer-size'' para WSGIDaemonProcess.
¿Puede indicar qué aplicación y qué encabezado era tan grande que se alcanzó el límite? Quisiera saber qué otras aplicaciones web Python además de Keystone están generando encabezados tan grandes si es una aplicación de uso común.
Una segunda posibilidad, derivada de la referencia ''truncada'' en ese mensaje, es que su proceso demonio mod_wsgi colapsó. Sin embargo, no dice que vio un ''Error de segmentación'' o un mensaje similar que indica que se produjo un bloqueo. Verifique eso y, si hay otros mensajes en el registro de errores en ese momento, indique cuáles fueron y puede verlo como el problema principal.
Resultó ser el problema real. El problema era más profundo, ya que cambié Cairo a CairoCffi y el RSVG-Handler no pudo tratar con el Contexto-Objeto proveniente de Cffi. No, mi problema actual es tener una lib de Python actualizada que me permita convertir svg en png. Usar svg2png desde CairoSVG no me funciona. Obtengo un
cairo devolvió CAIRO_STATUS_NO_MEMORY: sin memoria
Error, de lo cual estoy seguro, que no dice la verdad otra vez y el problema está en otra parte. Pero veamos.
Tuve un problema con esto en el servidor de CentOS 7 al implementar Django usando httpd con mod_wsgi 4.5.4 . Tuve que volver a usar mod_wsgi 4.3.2 que resolvió mi problema.