Selective disabling of headers in a multipart POST

Gatling (Open-Source)
1

G’day folks.

I need to be able to send a mixed multipart POST to a REST endpoint. My (sanitised) Gatling code:

exec(http(“SomeRequestName”)
.post("/some/api/endpoint")
.headers(scenarioHeaders)
.header(“Content-Type”, “multipart/mixed”)
.header(“Accept”, “application/vnd.some.stuff+xml”)
.bodyPart(StringBodyPart("")
.contentType(“application/vnd.some.stuff+xml”)
)
.bodyPart(ByteArrayBodyPart(“X-Attach: foo.txt\r\n\r\nWFhYWFhYWFg=”.getBytes())
//.contentType("")
//.dispositionType(null)
)
)

is being rejected (400 Bad Request) with:

com.pany.extapi.module.exception.MultipleAttachmentHeadersFoundException: Attachment multipart contained multiple headers [content-type, content-disposition], only a single header should be provided

The API documentation states no headers should be sent in the second body part. The following is a snapshot of what Gatling is sending:

–n5MUMlW_XCkH2AYDX-QOlHHqBmhdltF
Content-Disposition: form-data
Content-Type: application/octet-stream

X-Attach: foo.txt

WFhYWFhYWFg=
–n5MUMlW_XCkH2AYDX-QOlHHqBmhdltF–

You can see in my code snippet that I’ve tried to disable these two headers by setting an empty string and a null, neither of which works.

My trusty old LoadRunner script conforms by not sending any headers, and the request is accepted.

How to do this with Gatling? Any help much appreciated.

Nige

2

Could be wrong defaults in AsyncHttpClient multipart support.
Or could be a design issue in your API that could not be conforming to multipart spec, “The API documentation states no headers should be sent in the second body part.” sounds very awkward to me and your Exception seems to suggest proprietary multipart implementation.

I hope to be able to find some time some day to review AHC multipart implementation but I’m afraid that won’t happen any time soon, except if it becomes a priority for some customers. Otherwise, feel free to investigate on the AHC side and maybe contribute.

Regards,

3

G’day Stéphane.

Yes, there’s a thought or two that the implementation could have been done better (we’re talking c. 2010). To the best of my knowledge, there’s no reworking planned. I’m stuck with it.

A meaningful investigation is a little beyond my ability.

Perhaps not the ultimate reference, but https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition states:

In a multipart/form-data body, the HTTP Content-Disposition general header is a header that can be used on the subpart of a multipart body to give information about the field it applies to

The key word (for me) is can, as distinct from must, so couldn’t this be optional? Regardless, that leaves Content-Type to deal with…

Cheers,
Nige

4

The best way is probably to manually craft the request body.