Skip to main content

Content Starts Here

Troubleshooting issues with adding attachments to REST multipart requests

The article describes how to troubleshoot the issue with adding attachments to REST multipart requests.

To get the basic understanding of how to send a binary file along with a REST request in ReadyAPI, please refer to this video:

If you send an attachment in a multipart message, the default request can have data in headers that may be considered incorrect by your server and thus this request won't be processed successfully. To find the cause of the issue, compare a successful (or expected) raw request with a raw request from ReadyAPI:
* To get a raw request in ReadyAPI, please switch to the Raw tab on the left side of the Request Editor.
* To get a raw request which was sent from a browser (or from another application) you can use Fiddler ( which is a free tool to capture HTTP(S) traffic.

Please see the sample screenshot of the request which you can get in ReadyAPI.

User-added image

Here is the list of possible issues with this request and solutions to fix them.

  1. The Content-Type header is incorrect. 

The Content-Type header should be set to multipart/form-data or multipart/mixed. To set it, switch the Media Type value to 'multipart/form-data' ('multipart/mixed') on the Request tab in the Request Editor.

User-added image
  1. The boundary parameter in the Content-Type header is quoted when using ReadyAPI.

Please see the example of the Content-Type header below:

  • Content-Type: multipart/form-data; boundary="----=_Part_5_878045846.1497938035621"

According to the standard RFC2616, a quoted boundary is valid. But, there is a bug in the Apache Wink library that doesn't allow processing a quoted boundary header:, so the server does not recognize the boundary with quotes in multipart/form-data. If you cannot change the server logic, use the following groovy script in the RequestFilter.filterRequest event handler to remove the quotes. For details, see the Handling Events article.


import org.apache.http.client.methods.HttpRequestBase
import com.eviware.soapui.impl.wsdl.submit.transports.http.BaseHttpRequestTransport
HttpRequestBase httpMethod = (HttpRequestBase) context.getProperty(BaseHttpRequestTransport.HTTP_METHOD)
String contentTypeHeader = httpMethod.getHeaders("Content-Type")[0]
String boundary = "boundary="
int ix = contentTypeHeader.indexOf(boundary) + boundary.length() // =44 index of a part after boundary=
String contentType = "Content-Type: "
int icontentType = contentType.length() // =14 index of a part after Content-Type:
String fixedContentType = contentTypeHeader.substring(icontentType, ix) + contentTypeHeader.substring(ix + 1, contentTypeHeader.length() - 1)
httpMethod.setHeader("Content-Type", fixedContentType)

  1. The Content-Type header of the body part has extra data.

The Content-Type header in the request from ReadyAPI can have an additional name parameter. To modify the header value, you can use the RequestFilter.filterRequest event and the below Groovy script.


def bodyPart = context.getProperty("httpMethod").requestEntity.message.content.getBodyPart(0) // get a part by number, it starts with 0
bodyPart.addHeader("Content-Type", "application/octet-stream") // specify the value without the name parameter 

Note: The current behavior of ReadyAPI follows the RFC standards. The service must be able to handle situations when the Content-Type header has some parameters. Please refer to the "The Content-Type Header Field" article for details:

  1. The request from ReadyAPI has the "Content-Transfer-Encoding" header.

By default, ReadyAPI sends the "Content-Transfer-Encoding" header in the attachment part. To remove it, add the following script to the RequestFilter.filterRequest event.


def bodyPartAttach = context.getProperty("httpMethod").requestEntity.message.content.getBodyPart(0) // get a part by number, it starts with 0

If you have several parts in your request, don’t forget to change the parameter of the getBodyPart method to the appropriate value.

Note: Sending the Content-Transfer-Encoding header doesn’t violate RFC standards:, so it should not cause any problems if the web service handles requests correctly.

  1. The "name" parameter in the Content-Disposition header has an incorrect value

By default, the "name" parameter has the same value as the "filename" parameter (the name of the attached file), but your REST API may expect it to be different (the quite typical values are “file” or “payload”). In this case, set the expected value in the ContendID filed on the Attachments tab of the Request Editor.

User-added image

Please see the sample of the request after applying all the mentioned steps:
User-added image
Previous MonthNext Month