I am unable to overwrite the Content-Type

Your question may already have an answer on the community forum. Please search for related topics, and then read through the guidelines before creating a new topic.

Here’s an outline with best practices for making your inquiry.

My question:
I try to overwrite the automatically generated content-type by application/json but I am not able to fix that. How can I do that? The information icon says use the body to control the value?

Details (like screenshots):

How I found the problem:
I am getting a 415 unsupported Media Type

I’ve already tried:
Add content type in body and header.

The information icon suggests “Use the request body tab to control the value or to remove this header”. Next to the Headers tab, find the Body tab where you can update the content type of the request body. For example, if you wanted application/json, select Raw , and then JSON. Postman will auto-generate the header according to the request body you configured under the Body tab.

To overwrite an auto-generated header, you can’t edit the auto-generated values. However, you can add a new header, and de-select the auto-generated one.

This is such an appalling anti-feature. So unintuitive.

3 Likes

Hi, confused user here. :confused:

The OP is making a PUT request, and their fix was simple enough (even if @crashandburnuk very correctly commented that this is not really very intuitive).

I have also found out that things are a bit easier when making a POST request. In that case, Postman does respect the Content-Type header. At least, that’s what I’ve found out. That’s true even if the payload on the body is empty (length zero), which technically would mean that the Content-Type would not apply (on the other hand, one might argue ad infinitum that a payload of zero bytes can have any Content-Type — since zero bytes is a valid length for a payload :slight_smile: )

Now… how to accomplish the same with a GET request…?

For GET, Postman allows a payload to be sent (which is not forbidden) and so it follows that it should be possible to set the Content-Type as well. However, Postman (as well as others, such as — allegedly — .NET) does not allow that type of configuration.

curl has no problem whatsoever, it’s totally agnostic to what you do or don’t do, so long as it’s not explicitly forbidden by the specs.

According to the specs, if one wants that the reply to a GET request to explicitly be in, say, JSON or XML (as opposed to the default, whatever that might be), one ought to place Accept headers indicating the content-type preference. Sadly, though, many (most?) APIs simply couldn’t care less about Accept headers, and just send whatever the server wants — unless the request does, indeed, specify Content-Text… which is not possible to configure in Postman for GET requests.

It seems to me that there is a slight inconsistency on Postman’s interpretation of the specs. Either GET cannot have a payload, and then the request body should be greyed out (and no Content-Type header is sent); or, like curl does, if a payload is allowed with GET, then setting the Content-Type should be possible, too — even if the body is empty!

I’m not an expert in interpreting the specs, mind you. Exchanging a few cool posts with Tim Berners-Lee when he announced his ‘cool new idea’ in the early 1990s does not make me an ‘authority’ :slight_smile:

(not really worth taking a look, but here’s the link to my public workspace)

What if you want to just post form data that is NOT multipart/form-data, but a simple text only form? Makes no sense that it defaults to multipart forms when you check the “form-data” option, then you constantly have to manually change Content-Type. Why make things extra difficult?

1 Like

You could use this in the pre-request script to programmatically change the header:

Insert the specified header name and value (if the header doesn’t exist, otherwise the already existing header will update to the new value):

pm.request.headers.upsert({key: headerName:String, value: headerValue:String}):function)