request.body_file will protect you against bad WSGI servers/clients not sending appropriate headers. It'll return you something that you can read from, even if it is 0 bytes. It will also not let you read past the end of the input.
request.body_file_seekable will return the same thing as request.body_file but in a way that you can seek it, this will cause WebOb to make a copy of the whole body first (if the underlying body_file_raw isn't seekable). This likely already happened anyway if you are using pyramid_retry. Feel free to use this as well. > On Apr 17, 2018, at 07:30, Zsolt Ero <[email protected]> wrote: > > OK, I'm getting there, althought I'm still confused a bit. In WebOb > docs I found request.body_file, request.body_file_raw, > request.body_file_seekable. > > In multipart's request.POST, I'm doing: > > file_obj.seek(0, 2) > file_size = file_obj.tell() > file_obj.seek(0) > > Should I be using seekable or raw for this? You are not guaranteed to be able to seek the thing returned from request.body_file_raw. It'll likely be fine because of pyramid_retry, but if you don't have that, then it depends on your WSGI server. Use request.body_file_seekable to be safe. That being said, you don't need to .tell() to get the length of the upload, that's what the request.content_length is for. The content_length matches what is available to be read from the body_file, if and only if, the WSGI server you are using does not support for `wsgi.input_terminated` which would allow streaming a file using chunked encoding, in which case the underlying body_file_raw does properly EOF, but it likely won't support seeking. Tl;dr: use request.body_file or request.body_file_seekable if you need to seek. > > Zsolt > > > On 17 April 2018 at 15:10, Zsolt Ero <[email protected] > <mailto:[email protected]>> wrote: >> I've realised the following: >> 1. If I don't specify Content-Type, curl defaults to x-www-form-urlencoded >> 2. What I thought is the binary file's contents as a string is >> actually not working reliably. On an XML upload of a single file I get >> thousands of items and request.POST.items() looks like: >> ['<?xml version', 'amp', 'lang', 'amp', 'lang', 'amp', 'lang', 'amp', 'lang'] >> 2. The binary string I can use is actually request.body. Still, is >> there any potential problems with handling this as string and not as a >> file object? >> >> Zsolt >> >> On 17 April 2018 at 14:24, Zsolt Ero <[email protected]> wrote: >>> Hi, >>> >>> I'm trying to implement an API to a website which didn't have an API >>> yet. It's purpose will be to allow file uploads from 3rd party native >>> apps. >>> >>> I'd like to implement the API like Dropbox v2 API, just as a good >>> reference for API design. >>> >>> It's upload endpoint has the following specs: >>> https://www.dropbox.com/developers/documentation/http/documentation#files-upload >>> >>> And the following cURL example: >>> >>> curl -X POST https://content.dropboxapi.com/2/files/upload \ >>> --header "Authorization: Bearer " \ >>> --header "Dropbox-API-Arg: {\"path\": >>> \"/Homework/math/Matrices.txt\",\"mode\": \"add\",\"autorename\": >>> true,\"mute\": false}" \ >>> --header "Content-Type: application/octet-stream" \ >>> --data-binary @local_file.txt >>> >>> Now my problem is that I've implemented most parts, but if the request >>> has --header "Content-Type: application/octet-stream" then WebOb >>> doesn't allow using request.POST. It says: >>> >>> Not an HTML form submission (Content-Type: application/octet-stream) >>> >>> If I remove that header, I can use request.POST.keys()[0] to read the >>> contents of the file as a string. >>> >>> My question is: >>> 1. What am I doing wrong that the Content-Type is not supported? >>> 2. Is there any downside of having an up-to-100 MB file as a string? >>> Wouldn't the HTML multipart-form-data's file solution use less memory? >>> Can I make WebOb handle this kind of uploads like it does multipart >>> ones? >>> >>> Zsolt > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/CAKw-smBHD9Dg45R1UCu47NTQzYR1H1xdq8_RFyG4E0EKb0zsDw%40mail.gmail.com > > <https://groups.google.com/d/msgid/pylons-discuss/CAKw-smBHD9Dg45R1UCu47NTQzYR1H1xdq8_RFyG4E0EKb0zsDw%40mail.gmail.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/6894E200-F743-4A02-A90A-692A4E5C35D5%400x58.com. For more options, visit https://groups.google.com/d/optout.
