Cómo hacer una solicitud fragmentada a través de nginx

Question

Parece que nginx no admite bien las solicitudes fragmentadas. Pero estoy tratando de obtener una respuesta más definitiva (y actual). Tengo un cliente que realiza una solicitud SOAP a un servidor desde un cliente Java que establece el encabezado Transfer-Encoding: chunked. Todo funciona bien cuando me conecto directamente a mi aplicación en Tomcat.

Pero cuando pongo nginx entre ellos, entonces las cosas se rompen.

Para agregar algunos detalles: Estoy trabajando con CloudFoundry. Estoy usando Micro Cloud Foundry para confirmar que todo funciona como se espera en ausencia de nginx. Pero mi requisito es usar cloudfoundry.com, así que no tengo la capacidad de evitar nginx allí.

This question and answer dice que esta es quizás mi única solución: http://wiki.nginx.org/NginxHttpChunkinModule. Pero esa solución no está disponible, ya que no puedo modificar la configuración en cloudfoundry.com.

This question parece similar también, pero en realidad cubre el reverso de este requisito. Cubre las respuestas fragmentadas en lugar de las solicitudes fragmentadas.

Entonces, ¿qué hay de los cambios en el cliente para evitar esto? ¿Es posible enviar Transfer-Encoding: chunked y Content-Length: 123 como encabezados? Esta área es nueva para mí, pero parece de proyectos como Apache HttpComponents que uno establecería la longitud o fragmentación pero no ambos. El punto de fragmentación es que no necesita saber la duración cuando comienza la solicitud. ¿Podría decirle a mi cliente que use HTTP/1.0 y juegue bien con nginx sin fragmentar? ¿Hay otras ideas alternativas que me estoy olvidando?

Answer 1

He reunido las respuestas a todas las partes de esta pregunta.

Base nginx no es compatible con solicitudes fragmentadas (como Alexander confirmó!). Nginx puede admitir solicitudes fragmentadas utilizando NginXHttpCunkinModule (como mi pregunta menciona). Mejor: este módulo se graduó del estado beta a la calidad de producción hace más de 18 meses. Lo mejor: hablé con algunos miembros del equipo de ingeniería de CloudFoundry en un reciente meetup; confirman que está previsto agregar este módulo a su versión de nginx. Problema resuelto. (Bueno, está completamente resuelto a largo plazo. Pero no tenemos una fecha exacta para cuándo esperar esto.)

Por lo tanto, una solución a corto plazo también sería agradable. Encontré uno.

Respondiendo a mi pregunta dirigida a Alexander: No es posible enviar "Content-Length" con mensajes fragmentados. Ese es realmente el sentido de los mensajes fragmentados: empiezas a enviarlos antes de que tengas el contenido completo, por lo que posiblemente aún no puedas saber su longitud. Así que su idea de evitar solicitudes fragmentadas es correcta. Pero para ser más práctico, diría: "Use HTTP/1.0 en lugar de HTTP/1.1". Esto tiene el efecto de no enviar mensajes fragmentados. Pudimos parchar a nuestro cliente temporalmente para probar esta idea. Funcionó. Pero no planeamos lanzar un parche público. Parece contraproducente hacer que todos usen un protocolo de diez años (¡y una biblioteca de cliente no soportada de 10 años!) Para resolver el problema en esta situación.

En su lugar usaré el cliente pirateado cuando sea necesario, enviaré un correo electrónico si otros lo necesitan, y esperaremos la actualización de CloudFoundry a HttpChunkin y HTTP/1.1.

Answer 2

Nginx no admite solicitudes fragmentadas de hecho. Devolvería 411 Content Length required en ausencia del encabezado Content-Length.

Como está controlando su código de cliente, supongo que la única opción es evitar el uso de solicitudes fragmentadas y especificar Content-Length explícitamente.