Skip to main content

Adding MIME headers to MTOM Attachments...

1 reply [Last post]
Joined: 2012-11-09


I have been trying to get MTOM attachments working with a service client and have had a minor problem while sending files to the server. I am using JAX-WS 2.1.4 and SAAJ 1.3.2 but have verified the problem still exists in JAX-WS 2.2.7.

It seems the that the MtomCodec uses static MIME headers and doesn't allow someone to configure headers through the AttachmentPart.addMimeHeader() interface method.

The service I am communicating with is complaining that I have not specified the filename of the attachment in the content type. I have tried adding the "Content-Disposition" header:

        DataSource ds = new FileDataSource(file);
        AttachmentPart attachmentPart = soapMessage.createAttachmentPart(new DataHandler(ds));
        attachmentPart.addMimeHeader("Content-Disposition", "attachment; name="" + file.getName() + """);

And if I use the SOAPMessage.writeTo(System.out) method, it shows the header in the message:

Content-Type: application/octet-stream
Content-ID: test_0001.csv
Content-Disposition: attachment; name="test_0001.csv"

However, capturing traffic using Charles Proxy reveals the header is not added to the actual message sent across the line:

Content-Id: <test_0001.csv>
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

I have traced out the found and found it was because the MtomCodec uses statically set headers.

I have reviewed the XOP and MTOM specs and realize the headers written do conform to the specs. However, tools such as SoapUI do include the "Content-Disposition" header when enabling MTOM which leads me to believe that this is not a non-standard implementation request.

Is this something that can be filed as a bug report?



Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2012-11-09

I just want to mention, for the benefit of anyone running into this issue, that I was able to work around it by setting the name as a Content-Type parameter instead of adding the Content-Disposition parameter.

I am still wondering if the API shouldn't allow someone to configure headers though...