¿Puede Cherrypy recibir POST multipart / mixed fuera de la caja?

Question

Estamos recibiendo algunos datos POST de xml + archivos binarios arbitrarios (como imágenes y audio) de un dispositivo que solo nos proporciona codificación multiparte / mixta.

He configurado un controlador Cherrypy upload / POST para nuestro receptor. Logré permitirle hacer un número arbitrario de parámetros usando multipart / form-data. Sin embargo, cuando intentamos enviar los datos mixtos de varias partes, no estamos recibiendo ningún procesamiento.

@cherrypy.expose
def upload(self, *args,**kwargs):
    """upload adapted from cherrypy tutorials

    We use our variation of cgi.FieldStorage to parse the MIME
    encoded HTML form data containing the file."""

    print args   
    print kwargs

    cherrypy.response.timeout = 1300

    lcHDRS = {}
    for key, val in cherrypy.request.headers.iteritems():
        lcHDRS[key.lower()] = val
    incomingBytes = int(lcHDRS['content-length'])

    print cherrypy.request.rfile 

    #etc..etc...

Entonces, cuando se envían datos multiparte / formulario, args y kwargs están bien definidos.
args son los campos de formulario, kwargs = hash de vars y valores. Cuando envío multiparte / mixto, args y kwargs están vacíos, y solo tengo cherrypy.request.rfile como la información POST sin procesar.

Mi pregunta es, ¿Cherrypy tiene un controlador incorporado para manejar la codificación multiparte / mixta y fragmentada para POST? ¿O tendré que reemplazar el cherrypy.tools.process_request_body y lanzar mi propio decodificador?

Parece que el servidor wsgi integrado con cherrypy maneja esto como parte de la especificación HTTP / 1.1, pero parece que no puedo encontrar documentación en cherrypy para acceder a esta funcionalidad.

---

... para aclarar

Estoy usando la última versión 3.1.1 más o menos de Cherrypy.

Hacer un formulario predeterminado solo implica hacer parámetros en la función de carga.

Para el multipart / form-data, he estado llamando curl -F param1=@file1.jpg -F param2 = algo siguiente -F param3=@file3.wav http: // destination: port / upload

En ese ejemplo, obtengo:

args = ['param1','param2','param3] 
kwargs = {'param1':CString<>, 'param2': 'sometext', 'param3':CString<>}

Al intentar enviar el multiparte / mixto, intenté mirar request.body, pero seguí obteniendo Ninguno para eso, independientemente de establecer el procesamiento del cuerpo.

La entrada que estamos recibiendo viene como esta:

user-agent:UNTRUSTED/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
content-language:en-US
content-length:565719
mime-version:1.0
content-type:multipart/mixed; boundary='newdivider'
host:192.168.1.1:8180
transfer-encoding:chunked



--newdivider
Content-type: text/xml

<?xml version='1.0' ?><data><Stuff>....
etc...etc...

--newdivider
Content-type: image/jpeg
Content-ID: file://localhost/root1/photos/Garden.jpg
Content-transfer-encoding: binary

<binary data>

Tengo una sospecha furtiva de que el multiparte / mixto es el problema que Cherrypy me está dando solo el archivo. Nuestro objetivo es que cherrypy procese el cuerpo en sus partes con un procesamiento mínimo en el lado de recepción (es decir, deje que cherrypy haga su magia). Si eso nos obliga a ser más estrictos con el formato de envío para que sea un tipo de contenido que le guste a Cherrypy, que así sea. ¿Cuáles son los formatos aceptados? ¿Es solo multipart / form-data?

Answer 1

Mi mal. Siempre que el tipo de contenido sea del tipo "multipart / *", entonces CP intenta pegar el contenido en request.params (si hay otro tipo de contenido, entra en request.body).

Desafortunadamente, CP ha asumido que cualquier mensaje de varias partes es un formulario de datos, y no hizo provisiones para otros subtipos. Acabo de solucionar este problema en el troncal y debería publicarse en 3.1.2. Lo siento por los inconvenientes ocasionados. A corto plazo, puede intentar aplicar el conjunto de cambios localmente; ver http://www.cherrypy.org/ticket/890 .