By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,313 Members | 1,113 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,313 IT Pros & Developers. It's quick & easy.

Help: Uploading .zip to Python CGI

P: n/a
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).
Jul 18 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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

Jul 18 '05 #2

P: n/a
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?
Jul 18 '05 #3

P: n/a
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
Jul 18 '05 #4

P: n/a
> [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!
Jul 18 '05 #5

P: n/a
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
Jul 18 '05 #6

P: n/a
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

Jul 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.