Glenn Linderman <v+pyt...@g.nevcal.com> added the comment:
Pierre,
I applied your patch to my local copy of cgi.py for my installation of 3.2, and
have been testing. Lots of things work great!
My earlier comment regarding make_file seems to be relevant. Files that are
not binary should have an encoding. Likely you removed the encoding because it
was a hard-coded UTF-8 and that didn't work for you, with your default encoding
of cp-1252. However, now that I am passing in UTF-8 via the stream-encoding
parameter, because that is what matches my form-data, I get an error that
cp-1252 (apparently also my default encoding, except for console stuff which is
437) cannot encode \u0163. So I think the encoding parameter should be added
back in, but the value used should be the stream_encoding parameter. You might
also turn around the test on self.filename:
import tempfile
if self.filename:
return tempfile.TemporaryFile("wb+")
else:
return tempfile.TemporaryFile("w+",
encoding=self.stream_encoding,
newline="\n")
One of my tests used a large textarea and a short file. I was surprised to see
that the file was not stored as a file, but the textarea was. I guess that is
due to the code in read_single that checks length rather than filename to
decide whether it should be stored in a file from the get-go. It seems that
this behaviour, while probably more efficient than actually creating a file,
might be surprising to folks overriding make_file so that they could directly
store the data in the final destination file, instead of copying it later. The
documented semantics for make_file do not state that it is only called if there
is more than 1000 bytes of data, or that the form_data item headers contain a
CONTENT-LENGTH header (which never seems to happen). Indeed, I found a comment
on StackOverflow where someone had been surprised that small files did not have
make_file called on them.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
