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 information. 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.

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/

Status: Withdrawn"

They don't want to accept that they have a bug in their library. (I didn't withdraw it, they closed it that way)

I tried re-writing the export plugin to use only the "LrHttp.Post()" API, but with a large post (like an 15k image), it had the same problem.

If anyone else has experience to share on this topic, please reply. (This is not an offer to help with a bug inside Adobe, just curious if anyone else has this problem)

Interesting. Can you post an example of your export code? There are plenty of of export plug-ins that post images to websites and work. I have tested my latest export plug-in with files up to 80Mb so I wonder if it is something specific about your code or the file you are testing with.

I am the developper of the plugin, so I guess I can bring a little more information here. As far as I know, most users don't have any problem to upload large pictures, but I know some can not, for reasons I can not explain. I don't have the capacity nor time to test all configurations of my users, however, I try to stay as OS agnostic as I can, and for the moment, there is nothing I know of that is OS specific in my code.

Here is some code to explain how it all works :

The loop to process generated pictures :

for i, rendition in exportContext:renditions{ stopIfCanceled = true } do
-- Get next photo.
local photo = rendition.photo
local success, pathOrMessage = rendition:waitForRender()
-- Check for cancellation again after photo has been rendered.
if progressScope:isCanceled() then
break
end
if success then
local filename = LrPathUtils.leafName( pathOrMessage )
local caption = ''
-- Set the caption
if captionSetting == 'none' then
caption = ''
elseif captionSetting == 'filename' then
caption = filename
elseif captionSetting == 'title' then
photo.catalog:withCatalogDo( function()
caption = photo:getFormattedMetadata ( 'title' )
end )
elseif captionSetting == 'caption' then
photo.catalog:withCatalogDo( function()
caption = photo:getFormattedMetadata ( 'caption' )
end )
end
-- upload file to gallery
success = GalleryRemoteProtocol.uploadImage( serverId, albumName, pathOrMessage, caption )
if success ~= '0' then
-- if we can't upload that file, log it. For example, maybe user has exceeded disk
-- quota, or the file already exists and we don't have permission to overwrite, or
-- we don't have permission to write to that directory, etc....
table.insert( failures, filename )
end
-- When done with photo, delete temp file. There is a cleanup step that happens later,
-- but this will help manage space in the event of a large upload.
LrFileUtils.delete( pathOrMessage )
end

I did forward your message to one of our testers. He took the time to set up a Gallery server internally and create a reproducible test case that demonstrates a failure to upload large files with this plug-in. I haven't had the time to investigate this bug yet, but it is on my plate for LR3. (Sorry, can't provide info on when that will be available.)

I think, this is going to be very tricky to nail down and maybe to reproduce. The described problem seams to be at the TCP level, so the Gallery server is important there.

Bpub, can you tell :

Which OS/machine is used to run Gallery

Which webserver is used (and version)

Which PHP engine is used (and version)

Maybe we won't be able to reproduce the same conditions. I have a similar case with someone else running Gallery 1, and can not upload large pictures, but I can upload the same pictures on his Gallery installation from my Windows XP laptop. Weird...

Eric, if you need a test account on a Gallery 2, I can provide you with one. Maybe Bpub could do too, it might help.

Arnaud, I'll keep this in mind, but at this point, our tester has indicated that he was able to create a pretty solid reproducible case in-house. Hopefully that will be sufficient to figure out what's going wrong.

Additionnal information : I reinstalled Windows last week-end on my machine. This time I decided to give Windows 7 a try (after XP).

I tested the plugin and LR on Windows 7 and almost everything seems to be fine, except I cannot create any album. the Plugin seams to stop in LrHttp.PostMultipart (the last try I have is from the GetGalleryRemoteUrl within the parameters. So I think, something gets stuck in PostMultipart. However, I managed to upload very large pictures to the same Gallery using also PostMultipart.

By the way here is the code of the function to create an album. As you can see, this is not rocket science