As soon as I assumed that I would never need to use the multipart/form-data type to submit forms, I was proved wrong.
Since I read in this thread that the built-in services cannot be used, I decided to give it a try. And you guys were all right. It did not work.
But I spent a lot of time writing code to debug the problem and although it still did not work, I thought sharing my findings may enlighten somebody who can then show me the way too.
In our scenario we are posting to IIS (which may have its own problems). The web form contains a variable and a file variable. The mime message created by webMethods looks like the following :
Content-type=multipart/form-data;
boundary=“–=Part–123456789”
----=Part–123456789
content-type: text/plain
Content-Disposition: form-data; name=“var1”
content-transfer-encoding: 7bit
test
----=Part–123456789
content-type: application/octet-stream
Content-Disposition: form-data; name=“file1”; filename=“C:\test\test.xyz”
content-transfer-encoding: binary
text of the file
–=Part–123456789–
In this above message I am explicity setting the content-disposition headers for all variables and the encoding and content-type for the file variable. webMethods adds the
content-type: text/plain
content-transfer-encoding: 7bit
by default when not specified.
And therein lies the problem. The web server is not able to read the variable if it finds anything apart from content-disposition in the part. And that too after I fixed another problem.
And that is in the first line which is :
Content-type=multipart/form-data;
boundary=“–=Part–123456789”
webMethods IS adds a newline between form-data; and boundary. And it also quotes the boundary string. Both these are not liked by the web server.
If I remove the quotes around the boundary string, remove the newline after form-data and remove references to content-type and content-transfer-encoding from all non-file parameters, it works.
If anybody can get some new information from this and can help me out, I would be thankful.