Bug 60190 - Content-Type is added for POST unconditionally
Summary: Content-Type is added for POST unconditionally
Alias: None
Product: JMeter - Now in Github
Classification: Unclassified
Component: HTTP (show other bugs)
Version: 3.0
Hardware: All All
: P2 normal (vote)
Target Milestone: JMETER_5.0
Assignee: JMeter issues mailing list
Depends on: 62260
  Show dependency tree
Reported: 2016-09-29 18:12 UTC by Wyatt Epp
Modified: 2018-04-05 19:17 UTC (History)
2 users (show)

HTTP sample silently sent with extra header (3.50 KB, application/xml)
2016-09-29 19:31 UTC, Wyatt Epp
HTTP sample silently sent with extra header (8.56 KB, application/xml)
2017-01-28 11:54 UTC, Felix Schumacher

Note You need to log in before you can comment on or make changes to this bug.
Description Wyatt Epp 2016-09-29 18:12:31 UTC
For POST requests that don't set a Content-Type, JMeter will "helpfully" add "Content-Type: application/x-www-form-urlencoded".  It does this silently and unconditionally.

This causes all of our load scenarios to fail with 415 errors, and was a major pain to track down.

Distressingly, we discovered this even happens at recording time: we get the 415 response when the request is passed through the ProxyControl even though the browser doesn't send a Content-Type to be captured. (e.g. No Content-Type is recorded in the HTTPSamplerProxy's HeaderManager when this happens, either.)

I'm not sure what the correct fix for this-- it looks like this behaviour has been around since at least 2007, and longer for the HttpClient. (cf. Bug #40383)
Comment 1 Philippe Mouawad 2016-09-29 18:24:06 UTC
Could you provide a test plan showing the issue and how you would like it to be fixed ?

What you sent
What response you got
What request was expected ?
What test case is it ? 
What would you expect content-type to be ? 

Thank you
Comment 2 Wyatt Epp 2016-09-29 19:31:16 UTC
Created attachment 34315 [details]
HTTP sample silently sent with extra header

(In reply to Philippe Mouawad from comment #1)
> Hello,
> Could you provide a test plan showing the issue and how you would like it to
> be fixed ?

I've attached the JMX of the specific request that has the issue so you can see exactly what the structure is but, unfortunately, I don't think I can provide a whole working test plan because this is not a publicly accessible product.

To be clear:
- This sampler should NOT be sending a Content-Type.
- The browser request that this sampler was recorded from did NOT send a Content-Type.
- The server does NOT need one.
- JMeter is ADDING one even though we have not specified it in the Header Manager.

Again, I'm don't know for sure what would be a "good" fix for this.

I can definitely say that I DISLIKE that JMeter SILENTLY changes the request.  That's definitely bad.  If nothing else, that should log some kind of warning.

But is removing the behaviour that adds a Content-Type the correct answer?  Probably not; there have been bugs in the past that were fixed by adding it.

One possibility that may have some merit is a "HTTPSamplerVerbatim" type or an added flag in the HTTPSamplerProxy that signals the implementation that the request is expected to be passed to the host PRECISELY as it was recorded.  No additions or cleverness.  Everything that goes through ProxyControl instance should then have that type/flag

Another possible mitigation might be to set the Content-Type to whatever comes first in the Accept header instead of always using "application/x-www-form-urlencoded".  I still don't like it (and it should definitely still log a warning), but it would at least not cause things to break unexpectedly. 

Right now, I'm going to try working around this by adding another pass to our post-processing tools to catch any instance that a 415 was recorded and forcibly set it a Content-Type, but this is really not something that should need to happen.
Comment 3 Felix Schumacher 2017-01-28 11:54:17 UTC
Created attachment 34688 [details]
HTTP sample silently sent with extra header

Added a http mirror and a thread group so that this test can be run locally.
Comment 4 Philippe Mouawad 2017-09-03 16:46:46 UTC
How about not adding this anymore if not set and having a property that allows to do that ?

What is the risk ?

As per:

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". 

Comment 5 Michael Osipov 2018-04-03 14:43:19 UTC
I fully agree with Wyatt, this needs to be in control of the user, not JMeter. I cannot even remove it with: sampler.getHeaderManager().removeHeaderNamed("Content-Type").
Comment 6 Philippe Mouawad 2018-04-05 18:40:17 UTC
Will be fixed within Bug 62260
Comment 7 Philippe Mouawad 2018-04-05 19:14:33 UTC
Author: pmouawad
Date: Thu Apr  5 19:10:44 2018
New Revision: 1828467

URL: http://svn.apache.org/viewvc?rev=1828467&view=rev
Bug 62260 - Improve Rest support
This also fixes:
- Bug 60190 - Content-Type is added for POST unconditionally
Bug 60015 - Multipart/form-data works only for POST using HTTPClient4 while it should for PUT, DELETE...

Contributed  by UbikLoadPack
Bugzilla Id: 62260

Comment 8 Philippe Mouawad 2018-04-05 19:17:58 UTC
Issue is fixed, tests and feedback are very welcome

Comment 9 The ASF infrastructure team 2022-09-24 20:38:05 UTC
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/4123