I opened a Bug with Adobe, and they suggested I post here. I hope that someone within the LUA developer group hears this...
Here's how I described it to Adobe (case #0180990524):
And I quote:
When using LrHttp.post or LrHttp.postMultipart, the post transaction fails with the target website, because of invalid TCP header in
formation. This only occurs on large transfers, like multipart posts containing image files.
Using tcpdump command on Mac OS 10.5, I captured the header of the packets for a successful post, and a failed post.
19:48:24.212750 IP Macintosh.home.56274 > perfora.net.http: P 1:382(381) ack 1 win 65535
0x0000: 4500 01a5 6116 4000 4006 72a4 c0a8 0102 E...a.@.@.r.....
19:38:12.580630 IP Macintosh.home.56240 > perfora.net.http: P 3983702875:3983703256(381) ack 3995041646 win 65535
0x0000: 4500 01a5 c23b 4000 4006 117f c0a8 0102 E....;@.@.......
In the failed case, note the VERY large counter in the first line after "P".
The problem is that at the TCP layer, the computers have to agree on what part of the message is being sent. In the first case, it is from byte 1 to byte 382. In the second case, it STARTS with part 3983702875, which is completely invalid. The web server ignores the packet as corrupted, and the post command is unsuccessful. My guess is that Adobe has an un-initialized variable in their LrHttp library.
Here's Adobe's response:
I understand that you would like assistance with LrHttp.post and LrHttp.postMultipart. Adobe does not provide support for these methods at this level. For free assistance with this, you may refer to the forums online: http://www.adobe.com/support/forums/
They don't want to accept that they have a bug in their library. (I didn't withdraw it, they closed it that way)