Remove Content-Type header from JMeter HTTPSampler

Question

I have a JMeter (2.12 r1636949) test plan for a web application. A problematic step in the thread group is an HTTP sampler for a remote URI in the application that requires an HTTP POST with no Content-Type header or else it fails with an HTTP 500 error. Changing the web application is not an option - inspection of traffic with Fiddler shows browsers are capable of doing this.

How can I suppress sending of HTTP header Content-Type from a JMeter HTTPSampler?

What I've tried:

• Adding a HTTP Header Manager to the sampler with Content-Type set to blank (and to "REMOVEME")
• Adding a BeanShell PreProcessor with the following line: sampler.getHeaderManager().removeHeaderNamed("Content-Type");
• Setting the HTTPSampler "Browser-compatible headers" checkbox, because according to its documentation, this can suppress Content-Type but apparently only if "Use multipart/form-data for POST" is set. I cannot set this, because multipart is also not accepted by the webapp URI (a chiba XForms ...Flux/exec/Flux.fireAction path). The app appears to strictly require newline delimited body data but without Content-Type.

None of the above cause JMeter to successfully invoke the remote resource, or, for that matter, refrain from sending Content-Type. I've compared what I see in a View Results Tree to recorded app traffic in Fiddler, and all I can see different is the absence of Content-Type.

Raw request sample from Fiddler I am trying to recreate within the JMeter thread group:

POST http://hostname/AppName/Flux/exec/Flux.fireAction HTTP/1.1
Accept: */*
Accept-Language: en-us
Referer: http://...referer url...
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3; MS-RTC LM 8)
Host: hostname
Content-Length: 143
DNT: 1
Connection: Keep-Alive
Pragma: no-cache
Cookie: JSESSIONID=0000N1QLLDQCQycbKzkeaYFfCr3:18ujjmvjf

callCount=1
c0-scriptName=Flux
c0-methodName=fireAction
c0-id=9983_1420240552716
c0-param0=string:C187
c0-param1=string:1420240546765
xml=true

---

Update:

I am able to successfully invoke the server side URL by a bit of a JMeter hack. By following the 2.12 source (I set the sampler to HttpClient 4 to be sure) and scrutinizing the HTTP Sampler docs (particularly the MIME-Type notes for sending Files) I switched the sampler to the Parameters tab and moved the former Body Data contents to a text file now referenced as a single file to send with no Parameter Name and content type set to text/plain. However, the body content needs to be dynamic so a static file won't do - I need to reference a couple thread group variables. I'm currently researching how to read/write a file perhaps as a PreProcessor to set this content in a thread-safe manner, but this seems like a massive hack. I'm thinking this might be a worthwhile patch to allow Body Data with no content type, especially given the unsure TODO comment in the default case.

Answer 1

I worked around this by adding, before the HTTP Sampler, a BeanShell Sampler which returned the dynamic text (using vars.get(...)) as its "response". In that sampler I used a "Save Response to file" listener using a function for the per-virtual-user filename, storing the file name as a variable. In the HTTP Sampler, I used this variable in the File Path field, with an empty Parameter Name and text/plain for the MIME-Type.

The BeanShell script is below, if this helps anyone, as well as screenshots of the workaround.

//script for prepping Flux.fireAction request
sb = new StringBuilder();
NL = System.getProperty("line.separator");
sb.append("callCount=1").append(NL);
sb.append("c0-scriptName=Flux").append(NL);
sb.append("c0-methodName=fireAction").append(NL);
sb.append("c0-id=2728_1420218928279").append(NL);
sb.append("c0-param0=string:").append(vars.get("chibaIdFromRetrieveButton")).append(NL);
sb.append("c0-param1=string:").append(vars.get("chibaSessionKey")).append(NL);
sb.append("xml=true");
return sb.toString();

---