Service Virtualization

Hi Team,

I used a VS with STAND_IN behaviour which lose content-type in some cases.

- on request with response in VSI file, content-type is ok (application/json)

- on request with response from live invocation, status = 200 and body lenght >0, content-type is ok (application/json)

- on request with response from live invocation, status = 200 and body lenght = 0, content-type is ko (application)

But the content-type from live invocation is application/json even if body lenght = 0.

What can I do in order to keep the content-type from the live invocation ?

Best regards,

If you are in Live Invocation, then this is the real response and the real content-type coming back.  However if you want to override it (per say with what you always want it to be ), you can add a java step after the Live Invocation and before the responder, that intercepts the transient response and sets the content-type header, reset the response, then let it go on its way

I made a mistake, there is no content-type from live invocation when body lenght = 0.

So DevTest adds one, a bad one. Any idea in order to avoid this ?

From the HTTP 1.1 spec...

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

Are you sure that DevTest is setting Content-Type: application, or Content-Type: Application/octet-stream? 

In any case, you can still override it and remove the Content-Type post Live Invocation Step via a java step

I think what ellma10 is saying is that you could use a script to check the Live Response for a "Content-Type" parameter and, if not found, add one of your choosing. If Content-Type is in the parm list, DT would not override it with a different value.   

Done as a Scripted Assertion in the Live Invo step, with FAIL on False, it might look like this:

import com.itko.util.ParameterList;
import com.itko.lisa.vse.stateful.model.TransientResponse;

// get the live response and the metaData
TransientResponse tr   = testExec.getStateObject("lisa.vse.live.response").get(0);
ParameterList metadata = tr.getMetaData();

if ( metadata.containsKey("Content-Type") ) {
    // do nothing, Live provided one
} else {
   // add a content-type to the response
   metadata.addParameters("Content-Type=application/json");
   testExec.getStateObject("lisa.vse.live.response").get(0).setMetaData( metadata );
}

return true;

Yes that is what I was saying

Thanks to you two.

The scripted assertion had worked to add a "content-type" set to "json". But not to remove it (because the assertion seems to be run after sending response).

With a content-type set to json, the parser was trying to parse the body, with error because of body-lenght = 0.

Case 00867834 opened because in our situation, we do not have a body so we do not want a content-type to be added.