Help: Uploading .zip to Python CGI

[Will Stuyvesant]

I am uploading a .zip file to a Python CGI program, using a form on
a HTML page with

<input name="yourfile" type="file">...

In the Python CGI program I do:

import cgi
fStorage = cgi.FieldStorage()
zipdata = fStorage['yourfile'].value
print "Content-type: text/plain"
print
print len(zipdata)

Now the length of the zipdata is 100, where it should be about
2635...and unzipping it with zipfile of course gives the "not a zip
file" error.

The last part of the data that is received by the CGI script is:

\xf2\xf1!0\xdbS\xa9

and the next one *should* be \x1a

It seems that the .zip data is being truncated, but I don't know where
in my tool chain.
The strange thing is that the Python CGI script *does* work on a
Apache 1.3.27 server at work (unix), but gives the error above when
run on
my laptop with Windows XP and Apache 1.3.27 and also with the Apache
version 2.0.48 I tried later.

Does anybody have a clue what is going on?

Maybe the error is with the Windows version of Apache? Or is it a
Python problem (the unix server has Python 2.1.1).

[Jay Dorsey]

On Sat, Dec 06, 2003 at 12:40:43PM -0800, Will Stuyvesant wrote:

I am uploading a .zip file to a Python CGI program, using a form on
a HTML page with

<snip>

Without being able to see the form, I wonder if you're certain you set the enctype on the form to "multipart/form-data"?

You're working across multiple servers and if you're retyping the script each time its easy to forget the enctype of the form.

HTH
--
Jay Dorsey
jay at jaydorsey dot com

[Will Stuyvesant]

The problem I described in this thread is with Apache, not with
Python! And the unix Apache at my work has no problems, its only the
Windows Apache versions. So the Apache peeps will probably say it's a
*Windows* problem 0-)

I found out with the following: I can now avoid the first HTML page
with the .zip upload, instead I upload the .zip to my Python CGI
program with this little program:
import urllib
import webbrowser

webserviceURI = r'http://localhost/cgi-bin/mycgiprogram.py'
startpageName = 'start.xml'
# instead of a HTML page with INPUT type=file just read the file
fp = open(fname, 'rb')
data = fp.read()
fp.close()

# all CGI parameters in a dict, and encoded
params = urllib.urlencode({ 'yourfile': data })

# call the CGI program and read what it returns
f = urllib.urlopen(webserviceURI, params)
webpage = f.read()

# save it locally in a file
wpfp = open(startpageName, 'w')
wpfp.write(webpage)
wpfp.close()

# show it in your browser
webbrowser.open(startpageName)
--
If pro is the opposite of con, what is the opposite of progress?

[jmdeschamps]

hw***@hotmail.com (Will Stuyvesant) wrote in message news:<cb**************************@posting.google. com>...

I am uploading a .zip file to a Python CGI program, using a form on
a HTML page with

<input name="yourfile" type="file">...

In the Python CGI program I do:

import cgi
fStorage = cgi.FieldStorage()
zipdata = fStorage['yourfile'].value
print "Content-type: text/plain"
print
print len(zipdata)

Now the length of the zipdata is 100, where it should be about
2635...and unzipping it with zipfile of course gives the "not a zip
file" error.

The last part of the data that is received by the CGI script is:

\xf2\xf1!0\xdbS\xa9

and the next one *should* be \x1a

It seems that the .zip data is being truncated, but I don't know where
in my tool chain.
.... Does anybody have a clue what is going on?

Maybe the error is with the Windows version of Apache? Or is it a
Python problem (the unix server has Python 2.1.1).

Had a similare problem with *.jpg uploads

uploading files with a shebang such as:
#! c:/python23/python -u
reolved it for me
the -u part telling Windows to get data "unbuffered", so I read somewhere...

Good weekend,

JM

[Will Stuyvesant]

> [jm*********@cvm.qc.ca]

Had a similare problem with *.jpg uploads

uploading files with a shebang such as:
#! c:/python23/python -u
reolved it for me
the -u part telling Windows to get data "unbuffered", so I read somewhere...

Great! Solved it for me too! Thank you!

[Robin Munn]

Will Stuyvesant <hw***@hotmail.com> wrote:

I am uploading a .zip file to a Python CGI program, using a form on
a HTML page with

<input name="yourfile" type="file">...

In the Python CGI program I do:

import cgi
fStorage = cgi.FieldStorage()
zipdata = fStorage['yourfile'].value
print "Content-type: text/plain"
print
print len(zipdata)

Now the length of the zipdata is 100, where it should be about
2635...and unzipping it with zipfile of course gives the "not a zip
file" error.

The last part of the data that is received by the CGI script is:

\xf2\xf1!0\xdbS\xa9

and the next one *should* be \x1a
\x1a is ASCII for Ctrl-Z, which is used in Windows as an EOF (End Of
File) marker.
It seems that the .zip data is being truncated, but I don't know where
in my tool chain.

Somewhere in your tool chain, something is opening a file in text mode
instead of in binary mode.

The fact that your CGI script works on Unix but fails on Windows is
further proof that the Ctrl-Z is being treated as EOF on Windows, since
Unix doesn't give that character any special meaning.

--
Robin Munn
rm***@pobox.com

[Andrew MacIntyre]

On Sun, 6 Dec 2003, Will Stuyvesant wrote:

The last part of the data that is received by the CGI script is:

\xf2\xf1!0\xdbS\xa9

and the next one *should* be \x1a

ISTR that \x1A is control-Z.

Which is the EOF character on CP/M derived systems, and is still
interpreted thusly in the most surprising places in software from Redmond.

As another poster suggested, the -u option is the usual solution.

--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: an*****@bullseye.apana.org.au (pref) | Snail: PO Box 370
an*****@pcug.org.au (alt) | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia