So now I have a parser in place and an abstraction to read the body as a QIODevice which in turn calls uwsgi_(read|readline|seek) However the seek method fails if there is no request->post_file, looking at the source uwsgi_request_body_seek I see the function only does something if post-buffering is in place, but in the second if where the buffer limit didn't reach to create a file I can't re-read the buffer still: ie seek(0) and try to read()
Should I read all the buffer and keep a second buffer instead? 2014-06-24 2:20 GMT-03:00 Roberto De Ioris <[email protected]>: > >> 2014-06-23 6:00 GMT-03:00 Roberto De Ioris <[email protected]>: >>> >>>> hi, >>>> >>>> I've been trying to get the uploaded files on a form, >>>> but I don't find where in the wsgi_request struct >>>> they are, I tried probably most of the params >>>> and none seemed to have it, I also tried to grep >>>> the code but nothing. What am missing? >>> >>> file uploads must be managed at the application level, you read the body >>> and the parse it to obtain the file (or files) chunks. >> Thanks, >> now I wonder if there is some option where uwsgi stores >> the body in a file? > > > if you enable post-buffering, the body of the request will completely read > and stored in memory or a file. But i strongly suggest you to avoid this > trick to read the body (pay attention, as i am talking about reading the > body, interpreting it as a file upload is part of your app layer). It is > something the user may want to control. > >> If so can I still use uwsgi_request_body_read to >> read it independently on how/where is it stored? > > uwsgi_request_body_read uses always the same chunk of memory, you call it > to get chunks and then you parse them to build a file. > > Generally file uploads are encoded as multipart/form-data, described here: > > http://www.w3.org/TR/html401/interact/forms.html > > basically every time you encounter the boundary string you start storing a > new file. > > So, there are no fields in uWSGI for file uploads, as they are managed at > higher (the application) level. > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
