I'm using WWWC v7.5 (maybe 7.3). I have a small program to test uploading a file to my web server from a VFP app. The server is running a WWWC app to receive it. Here is the test program running from VFP 9:

set procedure to c:\wconnection7\classes\wwutils.prg additive

CurrPath = set("Path")
set path to &CurrPath;c:\wconnection7;c:\wconnection7\classes

oHTTP = newobject("wwHTTP", "c:\wconnect7\classes\wwHttp.prg")

oHTTP.nHttpPostMode = 2
oHTTP.cContentType = "multipart/form-data"
oHTTP.AddPostFile("SigFile", "c:\temp\SignatureTest.bmp", .t.)
oHTTP.Post("http://192.168.50.92/UploadSigFile.tho")

So everything works good, the file, a bitmap image, is in cPostBuffer and seems to be sent to the server. At the server I get the file created on disk, but with zero bytes. Here's the code to accept the file:

loFiles = Request.GetMultiPartFiles("SigFile")

for each loFile in loFiles foxobject
	
	BMPFile = loFile.FileName
	FileExt = lower(justext(BMPFile))
	
	if upper(FileExt) = "BMP"
		
		NewFileName = "Invoices\" + BMPFile
		NewFileName = forceext(this.THFolder + NewFileName, FileExt)
		
		if strtofile(loFile.Content, NewFileName) > 0
			
			Response.Write("SUCCESS")
			
		else
			
			Response.Write("FAILURE")
			
		endif  && strtofile(loFile.Content, NewFileName) > 0
		
	endif  && upper(FileExt) = "BMP"
	
endfor  && each loFile in loFiles foxobject

So where am I going wrong with this? Is URLEncoding not happening and should (that seems to only happen when nHttpPostMode is set to 1 and I'm using 2)? I have c:\wconnect7 in the path, which is where wwIPStuff.dll resides, so I think it can find it. Tracing the code, it seems cPostBuffer is properly populated at the time the file is sent to the server and the data does arrive, but there seems to be a problem with the extraction into loFile. Any help would be appreciated.

Couple of things:

• Don't set the content type in the wwHttp call - nHttpPostMode=2 handles that and you shouldn't override it

On the server you should check and see whether the data is actually making it to the server properly. Change Request.Form() and see if you have a large form buffer (it'll be mixed data so binary will be in there so very large make sure you use an editor that can handle this (VS Code or EditPad do - notepad doesn't).

You can also check the Web Connection logs - if things are working correctly you should see the multi-part data that holds the file on the server.

+++ Rick ---

But if I don't set nHttpPostMode=2, then it gives me an error saying if I don't have it set to 2, then I can't post a file.

Also, the wwRequestLog table does have the file data in the ReqData field, which starts out like this and then has all the binary data from the BMP file that VFP does not display well.

&--------7cf2a327f01ae Content-Disposition: form-data; name="SigFile"; filename="signaturetest.bmp"

Also, I've been using Request.GetMultiPartFiles and Request.Form in an attempt to get one or the other to work, but no luck.

Rick, please read my replies above, but I'm wondering if there's a bug somewhere. In the image, you can see that I'm getting data, but the strextract delimiters may not be set properly (or something is wrong when posting the file). Anyway, lcDelim2 was set as "--" but with a preceding CR and LF (so 4 characters total). In the data, it looked like the trailing "--" was really just that . . . "--" with no preceding characters. When I changed the delimiter to be just "--" (dropping the leading CR and LF), I got a file that was 234 bytes. That is not a complete file, so it was damaged. But it seems to be progress. I'll try adjusting lcDelim1, but I have no idea why these delimiters are not working as intended.

EDIT: After posting that I see that there seem to be two dashes in that data long before delimiting dashes at the end. So that may be why I got partial data (if those are really dashes).

After going off on a lot of tangents thinking I'd called something wrong, set something wrong, whatever, the fix was in the GetMultipartFiles method in wwRequest.prg for this line:

ADDPROPERTY(loFile,"Content",Extract(@lcMultipart,CHR(13)+CHR(10)+CHR(13)+CHR(10),;
            CHR(13)+CHR(10)+ "--" + THIS.cMultiPartBorder,"",.t.))

I added the [ "",.t. ] at the end to indicate that the ending delimiter was not required. Still not sure why it's not put there when the file is uploaded. And maybe it is that I didn't set something correctly, but, for the moment, this is the fix.

This looks familiar 😄

There were some fixes in the multi-part upload bits in the last (v8.4) release that were fixed. I don't think that particular issue showed in 7.x as there was a major refactoring in both the client and I thought this was a regression due to those changes. The code update in 8.0 (and the very last releases of 7.x) was for multi-part file handling to support greater than 16mb files. Whenever that error was introduced (could have been before) it's fixed in the latest release.

From what I remember this was a very specific use case that was breaking - posting non-file vars with content types, and posting files without content types (which is actually what you're doing). When you post files you should always provide a content type realistically and without looking closely it looks like that's why that's failing.

IAC, there was some rigorous testing around the latest release so definitely sure that this is fixed.

+++ Rick ---

Maybe I'm misunderstanding, but I have this line in the code:

oHTTP.cContentType = "multipart/form-data"

But maybe you were referring to whether the file is a image file, text file, spreadsheet file, etc?