Forum Discussion

mazam's avatar
mazam
New Contributor
7 years ago

custom value for boundary in Content-Type header

My server is rejecting the POST request and the server support has told me that the issue is the boundary value in the POST. 

The Content-Type sent is as follows:

 

Content-Type: multipart/form-data; boundary="----=_Part_169_12725615.1519667201887"

 

I am told that the server does not accept any special characters in the boundary value. It should all be alpha numeric. Like e.g. a boundary="----boundary1" will be acceptable. 

 

Does anyone knows how to do this please?

    • mazam's avatar
      mazam
      New Contributor

      This does not solve my issue. I want to attach an audio file. If I put it's contents there then the file becomes corrupt. I need a way to be able to specify customer header which SOAPUI can use when attaching files.

  • JHunt's avatar
    JHunt
    Community Hero

    Hmm, if this was a SOAP request then there's an option for "Inline Files" but there isn't the same option for REST.

     

    In the source code (com.eviware.soapui.impl.wsdl.submit.transports.http.support.attachments.AttachmentUtils), the implementation for SOAP boils down to this, which is fairly straightforward:

     

     

      //...
    String content = null; byte[] data = Tools.readAll(in, -1).toByteArray(); //... content = new String(data); //...

     

    So, you can use the workaround Paul referred to, plus use an inline Groovy script to inline the file contents:

     

     

    Content-Type: multipart/form-data; boundary="----someboundary"

    ------someboundary
    Content-Type: application/octet-stream; name="audio.mp3"
    Content-Transfer-Encoding: binary
    Content-Disposition: form-data; name="audio.mp3"; filename="audio.mp3"

    ${=new String(new File('audio.mp3').bytes)}

    Note that the boundary value in the body needs two more hyphens than the boundary value in the header.

     

    To my eye, the request generated seems identical to a normal REST request with attachments, except for the boundaries. Plus if I send it to a local MockService it seems to parse it ok. So there's every chance this might work for you.