Http response validation/checks with multipart responses

Hi,

I’m currently struggling to make some checks/validations on multipart responses.
My response consists of two parts, the SOAP response and some binary data (MTOM response).
I.e. the body looks like this:

--uuid:e0bd3646-3aa4-460e-872b-ddb1d293dc16
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <root.message@cxf.apache.org>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
    ...
      <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"
         href="cid:d8a154a2-4d24-4f99-8b0d-741d51c73f99-1962@cxf.apache.org"/>
    ...
  </soap:Body>
</soap:Envelope>

--uuid:e0bd3646-3aa4-460e-872b-ddb1d293dc16
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <d8a154a2-4d24-4f99-8b0d-741d51c73f99-1962@cxf.apache.org>

// my binary data

The header of the response message has the following contentType:

Content-Type: multipart/related; type="application/xop+xml";
   boundary="uuid:e0bd3646-3aa4-460e-872b-ddb1d293dc16"; 
   start="<root.message@cxf.apache.org>"; start-info="text/xml"

When I use the bodyString() method, I get only the content of the first part (i.e. the SOAP-Message content starting with <soap:Envelope). The bodyLength() method also takes only the content of the first part into consideration.

The xpath() check on the other hand seems tries to use the whole response and fails, as it is no valid xml.

When using transformResponse(...) method, the response.body contains the whole body starting with --uuid:e0.....

Is there any other way than the transformResponse() to access the second part of the multi-part response and perform some checks on that part?

Hi,

No, we don’t have any built-in support for multipart responses, so you indeed have to parse the response bytes yourself.
I’d use bodyBytes().transform

Hi,

unfortunately, bodyBytes() returns only the bytes of the first multipart message, i.e. only the SOAP message like bodyString(). Also regex(..) receives only the body of the first part.

The only way I found so far to access the whole message is using the transformResponse() method.

unfortunately, bodyBytes() returns only the bytes of the first multipart message

This is not correct (or it’s a bug, but I doubt that).

bodyBytes() returns the bytes of the full HTTP response body.

bodyString() returns also the full response body, but decoded as chars (with the charset being either from the content-type header or by default, the one defined in Gatling’s conf), which is most likely a mess in your case as your response body is not text.

Is it possible that the order of check() and transformResponse() is not maintained and transformResponse()is always executed first?

So if I have something like this (Java):

  http("my http request")
           .post("url")
           .header(HttpHeaderNames.CONTENT_TYPE, "multipart/related; type=\"application/xop+xml\"")
           .bodyPart(ElFileBodyPart("requestTemplate.xml")
                                .contentType("application/xop+xml; type=\"text/xml\"")
                                .contentId("SOAP-Msg"))
           .check(status().is(200))
           .check(bodyLength().is(sizeOfAllMessaageParts))
           .transformResponse(extractTheSoapPart())
           .check(bodyLength().is(sizeOfSoapMsgPart))                      

I would expect that the order of execution is

  1. check(bodyLength().is(sizeOfAllMessaageParts))
  2. transformResponse(extractTheSoapPart())
  3. check(bodyLength().is(sizeOfSoapMsgPart))

I.e. the first bodyLength() check returns the length of the whole body, then the body gets reduced, and finally the second check returns the length of the transformed body.

However, it seems that transformResponse is executed first, as both bodyLength() calls returns the same result.

transformResponse is applied to the response prior to any check. The order you define checks doesn’t matter.

Thanks, that explains my problems…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.