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 Fawcettwrote: > 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 > >