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

[Friedman, Seth]

Thanks for the response--

--
> I'm seeing the source and received binary data differ.  The  
> filesizes are identical, but hex 90s are all converted to hex 3F.
The transformation from 90 hex to 3F hex should not be happending.  
You're sure the host is sending the 90 hex values? Right? Also, is  
the service you are calling publicly available so I could check out  
what is going wrong?
--

I did hex output comparisons on two instances of files sent via POST to remote server compared them against the original; files sent via POST had this one difference consistently.   I implemented what I needed via jakarta's latest httpclient (and via that POST the binary was not changed), but being able to keep http client libraries constitent would be nice, so a fix here would be appreciated.

As I recall I could see in the sniffer the 90/3F transcode happen before leaving my machine, e.g. verify my script was sending the binary data wrong, rather than an intermediary or the http server injecting something that caused it to be interpreted wrong. 

The project I'm working on is just bootstrapping now, so it's up/down regularly as we debug day-to-day.  If you're having trouble reproducing the problem I could set up a service for you to test this, though from my experience any http post handler works (we tried two in debugging this problem).  I can provide the binary test file I'm using also, both source/uncorrupted or dest/corrupted versions - i would suspect given a binary file of certain (albeit: unknown) characteristics, it should be reproducible with any http post receiver.   Also I can get you the hex output of source file vs hex of what is sent by the script.   
  
--
The getBody method of  
com.pushtotest.tool.protocolhandler.HTTPMultipartBody constructs the  
parts. It hard codes the file to be sent as the first part. I'll take  
a look at the RFC and see how it should be done. It's likely this  
will roll into the maintenance release for January.
--
Great.    Theoretically this detail shouldn't matter to what I'm doing, but it is a known deviation from the traffic a real user (e.g. ie/ff) generates, and therefore is a potential category of confusion for me to deal with.   I'd be curious to hear the outcome either way.

Best,
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 --------------
An HTML attachment was scrubbed...
URL: http://cake.pushtotest.com/pipermail/users/attachments/20061217/dab37bbf/attachment-0001.htm