[ptt-users] setFile corrupting data on multi-part HTTP POST?

Mark.Lutton at thomson.com Mark.Lutton at thomson.com
Sat Dec 16 19:41:18 PST 2006


I can verify the fix easily.  I have a script that requests a jar file from the server.  There's a bad byte in the first line of the hex dump of the file; also I can compare it to the correct file.
 
I don't know all the details of encoding and decoding in Java and Python.  Java's OutputStreamWriter and InputStreamReader have parameters that specify the character set (like "UTF-8").  Maybe Python has those too.  I guess you call URLConnection.getContentType(), get the encoding out of that and pass it to the InputStreamReader constructor.
 
Mark Lutton
Business Intelligence Services, a Thomson Business
 

________________________________

From: users-bounces at lists.pushtotest.com on behalf of Frank Cohen
Sent: Sat 12/16/2006 8:59 AM
To: TestMaker users list
Subject: Re: [ptt-users] setFile corrupting data on multi-part HTTP POST?



Thanks for posting the workaround Mark but this really should be 
fixed. I'm going to see what I can do in the short term.

When I have a fix are you available verify the fix works?

Thanks.

-Frank


On Dec 13, 2006, at 2:05 PM, <Mark.Lutton at thomson.com> 
<Mark.Lutton at thomson.com> wrote:

> What's probably happening in (1) is that ProtocolHandler is 
> assuming UTF-8 encoding.  I had the same problem in downloading 
> applet code.  Hex 85 in the file was converted to hex 26.
>
> I solved this by using Java.  Here is Jython code to use the Java 
> classes to download.  You can do something similar to upload data.  
> Wrap the file in a DataInputStream, read it and write it into the 
> connection's output stream.
>
> from java.net import URL, URLConnection
> from java.io import DataOutputStream, FileOutputStream, 
> DataInputStream
>
> myURL = URL('''http://localhost:8080/MyApp/applets/Applets.jar")
> cc = myURL.openConnection()
> jarFile = DataOutputStream(FileOutputStream("Applets.jar")
> inStream = DataInputStream(cc.getInputStream())
> inNum = inStream.read()
> while -1 != inNum:
>     jarFile.write(inNum)
>     inNum = inStream.read()
> jarFile.close()
> print "Applets.jar written"
>
>
>
> Mark Lutton
> Business Intelligence Services, a Thomson Business
>
>
> ________________________________
>
> From: users-bounces at lists.pushtotest.com on behalf of Friedman, Seth
> Sent: Wed 12/13/2006 4:44 PM
> To: users at lists.pushtotest.com
> Subject: [ptt-users] setFile corrupting data on multi-part HTTP POST?
>
>
>
> Hi,
>
>
>
> Two questions.
>
>
>
> (1)
>
> With the following excerpt of code,
>
>
>
> self.body.setFile(filetoupload, "video/x-ms-wmv", "Filedata")
>
> (..bunch of parameters..)
>
> self.response = self.http.connect()
>
>
>
>
>
> I'm seeing the source and received binary data differ.  The 
> filesizes are identical, but hex 90s are all converted to hex 3F.
>
> Is there an alternative to setFile() that would be more suited for 
> binary data?
>
>
>
> (2)
>
> In testmaker, the parts to the multi-part POST are generated 
> seemingly independent of the order that I add parameters.    
> Regardless of whether I put the setFile call at the beginning or 
> end of a series of self.body.addParameter() calls, I'm seeing the 
> file POSTed first of the parts of the multi-part post.    Looking 
> at the RFC (2388 http://www.ietf.org/rfc/rfc2388.txt sec 5.5) it 
> seems like this might actually matter.    Is there a way that I can 
> control ordering that the parts of a multi part post works?
>
>
>
> Thanks!
>
> seth
>
> _______________________________________________
> Users mailing list
> Users at lists.pushtotest.com
> http://lists.pushtotest.com/mailman/listinfo/users
>

_______________________________________________
Users mailing list
Users at lists.pushtotest.com
http://lists.pushtotest.com/mailman/listinfo/users


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 8033 bytes
Desc: not available
Url : http://cake.pushtotest.com/pipermail/users/attachments/20061216/f7f702e6/attachment.bin


More information about the Users mailing list