Better handling of StringIO objects in POST requests #1704
Unanswered
plotski
asked this question in
Potential Issue
Replies: 2 comments
-
Related to issue #1482 and fix #1537 Not sure. We'd also see the same error on files opened in text mode, so something that might well make sense here is to raise an error on files that are opened in text mode or on StringIO instances. |
Beta Was this translation helpful? Give feedback.
0 replies
-
The FileField class doesn't seem to do any checks on the file object, and file
objects can indeed be anything that has the expected methods, so isinstance
wouldn't work reliably.
https://docs.python.org/3/glossary.html#term-file-object
As far as I can tell, the only reliable way would be to fileobj.read(1) and
check if it returns str or bytes, then seek back. But I'm not sure if all file
objects are seekable.
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I just spent several hours debugging
LocalProtocolError("Too much data for declared Content-Length")
. I've figured out what's going on, but I don't know what the best fix would be or if this is entirely my own fault.I was passing a
StringIO
object to a POST request, e.g.:The
StringIO
object ends up inFileField.get_length()
, which callspeek_filelike_length()
, which correctly reports the the length of the string. However, we must know the length of the string asbytes
because that's what we need for the POST request.The fix is very simple: Use
BytesIO
instead ofStringIO
. But the error message was extremely unhelpful.Maybe
FileField
shouldn't accept aStringIO
object? Or maybe it should convert tobytes
first? Or maybe this is really obvious for anyone with more experience and there's no need to fix it?Beta Was this translation helpful? Give feedback.
All reactions