-
-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Text returned as byte object when using 'enctype="multipart/form-data"' in forms #1352
Comments
Original comment by Joel Rivera (Bitbucket: cyraxjoe, GitHub: cyraxjoe): That's the consequence of an optimization leaking the abstraction. You can fix that with something like this:
But I do think that there is a bug on the leaky abstraction and needs to be fixed. |
Original comment by Juern Brodersen (Bitbucket: juern_uni, GitHub: Unknown): For now I'm just using:
Would something like that break the optimization? |
Original comment by lakin.wecker (Bitbucket: lakin.wecker, GitHub: Unknown): Was this on python 3 or 2? I believe I am running into the same issue here on python 2. And I have a pull request that fixes it. Does this https://gist.github.com/lakinwecker/08b484b3ce12102ac3df reproduce the error for you? and if so, does applying this changeset - https://gist.github.com/lakinwecker/08b484b3ce12102ac3df fix it for you? |
Original comment by lakin.wecker (Bitbucket: lakin.wecker, GitHub: Unknown): I can confirm that I am seeing the same issue here in python 3. And that my pull request fixes it. |
Original comment by lakin.wecker (Bitbucket: lakin.wecker, GitHub: Unknown): Whoops. Yeah - I meant to link to this pull request: https://bitbucket.org/cherrypy/cherrypy/pull-requests/112/when-entity-parts-are-too-big-cp-writes/diff The basic problem is that once you hit 1000 it writes it to a file, and then reads from the file instead of just using memory. This particular optimization is useless, because the "write to the file" then "read from the file" happens within the same request and almost immediately after one another, so the savings you get in terms of unused memory is immediately negated. Also, that code path doesn't properly attempt to decode the incoming data using us-ascii or utf-8 while the path that reads only into memory does do this decoding. My pull request completely removes the optimization. I am thinking that this is ok, because as far as I can tell the optimization isn't sucessfull anyways. |
Original comment by Joel Rivera (Bitbucket: cyraxjoe, GitHub: cyraxjoe): I've been trying to profile the two approaches an so far the current implementation is a lot more efficient on the particular use case on which a input field is dumped into the file. I'm testing with 10 concurrent requests submitting 5 MB in an input field. This is the modified memory behavior: This is the original memory behavior: After covering that. I'm not implying that is something common to submit inputs of 5MB with 10 at a time without specifying a file name. But I just wanted to see the impact on removing this change. There is also the possibility that we just fix the optimization and make sure that it returns a string instead of bytes when the file was created because of the |
Original comment by Ben Bass (Bitbucket: codedstructure, GitHub: codedstructure): I've just encountered this issue in a project which recently moved from Python2 to Python3, exposing some nasty failures as bytes are used in dozens of different contexts which normally expect strings. I've addressed it in the short term with the following which seems to fix things in my case, but would be nice for this to get cleaned up - it's not at all friendly to Python3 use of CherryPy...
|
Fix released in 5.5.0. |
Originally reported by: Juern Brodersen (Bitbucket: juern_uni, GitHub: Unknown)
If you are using 'enctype="multipart/form-data"' in forms and putting more than around 1000 characters in a text field that text field will be returned as a byte object.
Using less characters in the text field will return a string.
Less than 1000 characters will return "class 'str'" more returns "class 'bytes'"
Tested with:
python 3.4
cherrypy 3.6
The text was updated successfully, but these errors were encountered: