Werkzeug: Las solicitudes fragmentadas todavía no funcionan

Creado en 16 jul. 2017 · 4Comentarios · Fuente: pallets/werkzeug

(Actualizado, porque me di cuenta de que había estado intentando solucionar este problema, así que me confundí con el problema original y el problema que me hizo darme por vencido)

Estoy haciendo una solicitud fragmentada a una aplicación que usa Werkzeug (actual maestro de git). get_input_stream termina llamando LimitedStream(wsgi.input, min(content_length, max_content_length)) . min(content_length, max_content_length) siempre será Ninguno si usa codificación fragmentada.

En un intento de progresar, intenté usar LimitedStream(stream, content_length or max_content_length) , pero luego termino obteniendo una excepción ClientDisconnected , porque no podemos distinguir la diferencia entre la desconexión de un cliente y la solicitud fragmentada que simplemente se realiza , ya que wsgi.input.read() solo devuelve una cadena de longitud 0 en ambos casos.

bug

Fuente

sorenh

Comentario más útil

¿Qué wsgi admite actualmente input_terminated ? Después de grabar todo el día depurando por qué los datos están vacíos, entonces por qué la transmisión está vacía y luego me doy cuenta de que se debe a la codificación de la transmisión fragmentada, ahora no puedo encontrar nada que admita esto: /

iScrE4m en 16 ago. 2017

👍2

Todos 4 comentarios

Esto es más que un simple error con min . Después de arreglar eso, el problema es que hacer wsgi.input.read(max_content_length) con bloques Werkzeug para siempre si hay menos de max_content_length para leer. O al usar Gunicorn, que admite fragmentos al analizar y almacenar en búfer todo el mensaje, la longitud es inferior a max_content_length , por lo que LimitedStream cree que el cliente se desconectó.

Probé esto en Django solo para asegurarme de que no estamos haciendo algo extraño, también ve un flujo vacío.

davidism en 21 jul. 2017

La forma más sencilla de avanzar es proporcionar un middleware que establezca environ['wsgi.input_terminated'] y le diga a las personas que lo usen cuando utilicen un servidor que admita la transferencia fragmentada.

davidism en 21 jul. 2017

iScrE4m en 16 ago. 2017

👍2

Además de marcar environ.get('wsgi.input_terminated') ¿deberíamos también marcar environ.get('HTTP_TRANSFER_ENCODING') == 'chunked' y, en ese caso, también devolver la secuencia sin envolver directamente? Eso soluciona problemas como un simple curl -H 'Transfer-Encoding: chunked' ... devuelve una secuencia vacía.

Según RFC2616

4.4.2
Si un campo de encabezado Transfer-Encoding (sección 14.41) está presente y
tiene cualquier valor que no sea "identidad", entonces la longitud de transferencia es
definido mediante el uso de la codificación de transferencia "fragmentada" (sección 3.6),
a menos que el mensaje termine cerrando la conexión.

4.4.3
Si hay un campo de encabezado Content-Length (sección 14.13), su
El valor decimal en OCTETs representa tanto la longitud de la entidad como la
longitud de transferencia. El campo de encabezado Content-Length NO DEBE enviarse
si estas dos longitudes son diferentes (es decir, si una codificación de transferencia
el campo de encabezado está presente). Si se recibe un mensaje con un
Campo de encabezado Transfer-Encoding y un campo de encabezado Content-Length,
este último DEBE ignorarse.

... observando que Transfer-Encoding de chunked exige que se ignore cualquier encabezado Content-Length , por lo que no se debe realizar ningún procesamiento de flujo basado en él. Este es el caso actualmente, a menos que se establezca wsgi.input_terminated .

¿Realmente debería ser necesario establecer wsgi.input_terminated para que funcione la codificación fragmentada normal, por ejemplo, de una carga útil JSON de 10 bytes?