Ah, thanks for the advice. You're right, the change is much cleaner
in publish.py's Publisher.publish_cgi() -- the binary mode switch for
stdout is already there.
--- /cygdrive/c/Quixote-1.0/publish.py 2004-05-18 21:33:04.000000000 +0200
+++ publish.py 2004-07-31 12:41:20.000000000 +0200
@@ -557,9 +557,10 @@
once and return.
"""
if sys.platform == "win32":
- # On Windows sys.stdout is opened in text mode by default
+ # On Windows stdout,in are opened in text mode by default
import msvcrt
msvcrt.setmode(sys.__stdout__.fileno(), os.O_BINARY)
+ msvcrt.setmode(sys.__stdin__.fileno(), os.O_BINARY) #for uploads
self.publish(sys.__stdin__, sys.__stdout__, sys.__stderr__, os.environ)
On Sat, 31 Jul 2004 05:34:44 -0400, Graham Fawcett wrote:
> Brendan T O'Connor wrote:
>
> > Hi,
> >
> > I was having problems with the file upload demo on Windows with
> > Apache/CGI. Turns out that to safely upload binary files, you have to
> > get sys.stdin to be in binary mode, else it quits reading once it hits
> > the first null byte. Here's my patch to upload.py which seems to
> > solve it on windows at least -- are there any problems with this?
>
> I haven't tested the patch -- but I wanted to add that this hasn't been
> necessary on win32 when using Medusa or Twisted, because they both use
StringIO
> to implement req.stdin.
>
> Setting binary-mode on stdin and stdout *might* be undesirable if Quixote is
> not running as a CGI application. I can't think of a killer case, but one
might
> exist... (I might, e.g., be collecting data from a Web UI, and writing it out
> to stdout, piped to a file... odd but possible.) At the very least, it would
be
> an unnecessary call for non-CGI processes.
>
> Perhaps it would be better to set these modes in the *CGI handler script
> instead of in upload.py? This might also make sense for FCGI/SCGI, so that the
> (perhaps small) overhead of the import and setmode() calls is not invoked
every
> time a file is uploaded, but rather once when the streams are connected.
>
> -- Graham
>
>