the best part is that if you use a NetWebServiceMethod it'll come with a CURL example already in the docs for you. !
Hmmm, where is that?
I did a grep and all I found was the Multisite- and PHP-example. One fined was calcUrl, the other was php_curl.dll.
Anyway, I got it working instantly, once I followed you advice, to set the type to FILE and use the proper fieldname.
Works like a charm! Everything from TXT to ZIP or JPG got send to and stored on the server.
However....
I expanded the cURL-commandline with a second parameter, a Description-field about the file, that gets uploaded.
curl -F "IncomingFile=@g:\cURL\yaddayadda.txt;type=multipart/form-data" -F "Description=Yadda Yadda" http://192.168.178.113:88/FileUploadStill all perfect! Except the fact, that if the contents of "Description" or the name of the "IncomingFile" contains special characters like german umlauts as äöü or ÄÖÜ or ß, which is quite probably to happen. Well, I am a bit confused about what happens when, because it all looks so weird to me. I took some screenshots to explain, what happens when.
The
first image is the cURL command itself. I created a TXT with the name rübärö.txt and take just that for the "Description" as well, to make things obious.
The
second image shows the incoming POST in the server. The filename has been received correctly (while the contents is displayed wrong, ought to be "kurz und bündig!", but finally gets stored correct, both filename and contents, so no problem here). The contents of "Description", which is just as the filename itself, is displayed correct.
When the file is stored successfully (or not), I return the result to the client. For this I extract the filename, using StringTheory .FileNameOnly() and take this + the Description, stuff it into a variable and send this variable back. As seen in
image three. I use the output into DebugView to display this. Cunningly the name of the file is correct here, while assigning to the variable. The description is already broken. All umluats are turned to ?. But it gets weirder! The next line, which starts with [st], comes directly from StringTheory. (I have checked debunggin on in the Template.) These four lines are actually what gets sent, and the umlauts are changed to some higgeldy-piggeldy, but very different to the ? in the Description.
But it still gets better.
Image four shows the incoming on the client-side, where it has turned into gobbledygoo.
Something is going on here, but I do not what and where. And because I do not believe in sorcery, there mut be a reason. A very well hidden reason. I have some guesses, but those guesses I tried were all proven wrong.
If it would be helpful I could pass this APP in for the next webinar.
Thanks for all your patience
Wolfgang