Nevermind, actually I'm doing something wrong when I qstrncpy the read char, after this uwsgi_body_ready() return empty strings so something is freeing it tho I explicity made a copy.
2014-06-27 12:30 GMT-03:00 Roberto De Ioris <[email protected]>: > >> 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? > > it depends by your framework. > > I would follow a "cheap" approach: bodies bigger than N (8megs ?) are > stored on disk, the others in memory. > > Technically this is what happens in post buffering mode. Maybe you can > simply force it (like we do in the rack plugin, as the rack specs enforce > seekable streams) > > >> >> 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 >> > > > -- > 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
