QUESTION Posting to a JSP from Flow

I am having difficulty posting to a JSP.

The author of the JSP has asked that I make a HTTP POST to a specific URL and that I use Content-Type=multipart/form-data.

I used the MIME services and think I have everything in working order.

When I use pub.client:http to call the JSP, however, the data returned to me by the remote Web server is the same HTML that is at the URL had I not invoked it via my Integration Server. That is, I can cut-and-paste the returned message into an empy text file, save it as “.html” and see the same results had I keyed in the JSP’s URL directly.

The JSP/HTML is expecting two inputs. One is of TYPE=file and the other is of TYPE=image. The code looks like this:


As I see it, I must not be properly constructing my MIME message. Can somebody walk me through the process for creating a multipart/form-data message to submit to a JSP with the variable types and names above?


Maybe a better way to pose this question is:

How can I simulate the submission of a FORM to a JSP where the FORM looks as below:



Dan: A google search on “Content-Type=multipart/form-data” showed up an example here:


See the section on “HTTP with multipart/form-data”.
This may help you. It looks like you have to build a document and submit it as bytes.

Also, this RFC – “Returning Values from Forms: multipart/form-data” – [url=“”][/url] – seems pretty pertinent.

Well, this was a tough one to solve but thank you, Sonam, for reminding me that Google is a great resource. Almost as good as this one! :wink:

I started to make progress only after I stopped relying on the webMethods IS MIME Built-In Services. I am not sure what the problem really was because I could not capture the exact HTTP POST that I made to the JSP. My guess is that the MIME messages constructed by the Integration Server either includes extra information that trips up the O’Reilly Servlet code or does not include enough information.

My guess is that the former is true.

When the error stack trace could finally be caught, it stated that there was “no separation boundary”. I had debugged the Flow quite heavily and knew that to be untrue so I went about deconstructing the MIME message and eventually pared it down to nothing but my data and the boundries.

The servlet still failed citing “no separation boundary”.

In the ultimate debug step, I disabled all of my MIME services and put in a simple MAP step.

I created a few string variables in the MAP step set their values according to my testing needs. I created Strings for name, filename, XMLToPost and – going against all of my better judgment – I created one for boundary.

Next, I created another MAP step, created a new String variable named “stringToPost” and set it to the following:

Content-Disposition: form-data; name=“%name%”; filename=“%filename%”
Content-Type: %httpParameters/urlInfo/contenttype%



Next, I used the pub.client:http service and mapped my stringToPost variable to the Service In variable Data/string. I also set the Service In variable headers to have a key-value pair of:
Wouldn’t you know it, this approach worked. The servlet was able to consume my data without a problem.

Thanks for your help again, Sonam. Who would have thought the easiest way would have been to build the multipart message by hand!

Hi Dan,
Your detailed explaination reminded me of the same problem I faced some time back.

I am sure if you explicity set the content-type to multipart/form-data;boundary="%boundary% in the headers input of pub.client:http flow, it will start working.

So I guess you can again start using the webMethods built-in services to generate the multipart message. Only caveat to it is that you will have to write a small java service which will break the mimeData/envStream to a String and http-mimeHeader, which you will use in your http post.

I guess, webMethods way of building mime-messages works only if you have webMethods at the other hand to deal with the incoming mimeStream !!

Let me know if you need me to post the sample code for breaking the mimeData to string and http-header.

Hope above Helps,

> Thanks for your help again, Sonam.
> Who would have thought the easiest way
> would have been to build the multipart message by hand!

Um, er… I did not consider the built-in MIME services… Sometimes ignorance is bliss, right?

Hopefully, with Saurabh’s help, the built-in services can be used too.

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: text/plain
Content-Disposition: form-data; name=“var1”
content-transfer-encoding: 7bit

content-type: application/octet-stream
Content-Disposition: form-data; name=“file1”; filename=“C:\test\”
content-transfer-encoding: binary

text of the file

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 :


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.

Rupinder, I think your debugging has helped us all reach a better level of understanding about using multipart MIME messages between Integration Server and a Web server.

My final solution was to write a service that builds the multipart message “manually”. The service is called “buildMultipartMessage” and it accepts a few inputs:

    []boundary – a random string used for boundarys []name – used for the “name” field []content-type – used to designate the content type (i.e. text/xml, application/pdf) []string – used for the body of the message between boundaries. This can be a string or a string-representation of a binary object.

    Each time that I want to add a new part to my multipart form-data, I will call this service and pass it the proper parameters – being careful to send the same boundary – and use pub.string:concat to add them together.

    When all parts have been added and my string is complete, I map that to the string element in the pub.client:http Service In variable. I also set the headers variable to the following:


This approach has served me well, Rupinder. Hopefully, it can help you.

Just wanted to post a big thanks to everyone on this thread - this is a great little HOW-TO for file posting using webMethods IS! I’m following the same general outline as Dan suggested in his last message and it’s working great in my initial testing. The only other thing I found is that you must NOT include the content-transfer-encoding line in the parts of your message - when I included this line, the field name was found but no data was returned. Dan’s suggestion doesn’t include the content-transfer-encoding line, for good reason as it turns out.

I’ve been reading through your thread about posting files to a JSP,
though mi stuck in one step… I haven’t managed to get it working, i
think it’s the way i’m doing things.

If not too much trouble let me describue what im doing so you may
correct, if you will of course:

  • Im doing a getfile of the file im attaching
  • transform it into a string
  • invoke an http with loadAs bytes, url, method post

I dont know if im setting the header as it should be, could you give me
a hand here? or screen scrap your service for me? it would be much

thanks in advance

File with POST request
prueba.xml (4.7 k)

Arturo, it looks like you’re trying to simply send an XML file via HTTP. If this is the case, then you can pass the XML as the data\string input to the http service, and add a name/value pair of Content-type=text/xml to the headers structure. If you’re trying to pass the file as well as some other variables, then you’ll need to use the multipart/form-data content type, as explained elsewhere in this thread.

Even though im trying to do just as you say i’ve unable to accomplish it. I’m sending the xml to the string part, setting the content-type as you say and still the JSP ain’t saving the file, nor seeing it. I’m debugging this on the JSP that receives the info and it isn’t getting the file part =(

Are you sure your JSP is expecting a HTTP post of an XML file? That’s what you’re trying to do, and it’s not really what this thread is about. If your JSP is expecting an XML file as part of a multipart/form-data post, then that’s more what this thread is discussing. It would be helpful to see some HTML code that your JSP does accept a submission from. For example, I can use the following HTML form to submit to a JSP that I’m using:

<TITLE>Receive File Test</TITLE>
<H1>Receive File Test</H1>
<FORM NAME=Upload ACTION=“http://localhost/myJSP” ENCTYPE=“multipart/form-data” METHOD=POST>
<P>Random Value: <input type=text name=“randomValue”>
<P>File to submit: <input type=file name=“fileContent”>
<P><input type=“submit” name=“upload” value=“Upload”>

I then wrote a service that emulates this HTML form by creating the following value in IS:

content-type: text/plain
Content-Disposition: form-data; name=“randomValue”


content-type: application/octet-stream
Content-Disposition: form-data; name=“fileContent”; filename=“%file/filename%”



The JSP receives the values properly when I use this value as my data\string http input, and the value multipart/form-data;boundary=%boundary% as the Content-type header.

Processing files in a JSP isn’t an area of expertise for me, so I have no idea if that JSP code will work. From the webMethods side, it looks like your submission is fine as long as you also set a string named Content-type in the headers structure to “multipart/form-data;boundary=%BbC04y”.

I tried to write a buildMultipartMessage as specified by Dan Green. The inputs are:
boundary – a random string used for boundarys
name – used for the “name” field
content-type – used to designate the content type (i.e. text/xml, application/pdf)
string – used for the body of the message between boundaries. This can be a string or a string-representation of a binary object.

The problem is when I try to send this MIME message to O’Reilly Servlet [url=“ | com.oreilly.servlet”][/url] running at my localhost [url]http://localhost:8080/multipart/servlet/requestupload[/url]
I got the "Corrupt form data: premature ending " exception. It seems like the servlet does not like the new line “\n”. Is any one can give me some help on this? Thanks in advance for your help.

Dear folks,
I’m getting “InputStream required” Exception when trying to send the MIME message to a remote service. The remote service using createMimeData service to receive this MIME message. I’m mapping Inputstream object created in local service to the Remote service.
This is working fine when pass the InputStream object created in the local server and your passing MIME message to the local createMimeData service.
Can anybody put some light on this.

Thanks in advance