You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying out upload files from a zip archive without splitting them apart on disk. I thought I'd be able to pass the InputStream directly into UploadIO.new and everything would be fine.
However, it looks like in order to multi-part the message body, it needs to know the length of the IO object. I'm happy to try adding this method, but is it even possible to know without reading the entire stream (and then rewinding it)?
The text was updated successfully, but these errors were encountered:
InputStream now has a size method for this sort of thing (#478). Is length effectively an alias for this? Zip bombs are a concern, but my reason for allowing this is that the receiver should be able to use the stated size to not accept any more data than that.
It's been so long since I opened this issue I don't recall all the details, but the gist was I wanted to wrap it in an UploadIO.new, which I think can take a File handler or any other IO that implements a few methods, and length was one of the methods it wanted.
Having looked at UploadIO I think it's only really designed for Files or file-backed IOs. File itself doesn't implement length, and this comment on UploadIO suggests that if you do supply an IO you need to also supply the file that contains the data as well - which you could only do for an entry from a zip file if you wrote it out to disk anyway. I think you could make it work with a StringIO - which is the one IO that does implement length and doesn't need a filename for UploadIO.
It seems complicated though. Not sure why the UploadIO folks don't use size as then you really could use any IO.
I'm trying out upload files from a zip archive without splitting them apart on disk. I thought I'd be able to pass the
InputStream
directly intoUploadIO.new
and everything would be fine.However, it looks like in order to multi-part the message body, it needs to know the
length
of the IO object. I'm happy to try adding this method, but is it even possible to know without reading the entire stream (and then rewinding it)?The text was updated successfully, but these errors were encountered: