Content-Type Header Automatically Added to GET Requests

I think there may have been a recent change/bug to Postman where it adds a Content-Type header to all requests. This is a problem for us since the 3rd-party API we consume doesn’t like when this header is specified for GET requests.

It’s also a problem for our team when using the Postman tool as it shows our requests have been modified (circle on the tab header) even though we have just opened it. We are warned that we have unsaved changes when we close the request tab down and have to click “Don’t save” every time.

Is there a way to prevent this header from appearing? Again, I don’t think this was happening in the past.

I am currently running the latest version of Postman:
Postman for Windows
Version 6.4.1
win32 6.1.7601 / x64

Hey @troylatchman
This has always been the behavior. We haven’t made any changes to the auto add headers behavior.

You would have been to a method with body and switched to URL-encoded body type, which added the header and switched then switched method back to GET.

Hence, that header is present there.

Hey @sujayvenaik

Thanks for your comment. I didn’t realize that the Content-Type was always auto-added.
If that’s the case, then maybe a better definition for the bug is: Content-Type auto-added for GET requests.

Here are the steps to reproduce.

  1. Have any GET request saved - I have a collection on the left-hand side with several of them.
  2. Close all requests down so that only a new “Untitled Request” remains open.
  3. Click on any GET request to load it into the editor.
  4. Notice that there will be a Content-Type set in the Headers section.
  5. Manually delete/uncheck the header from being applied.
  6. Hit Save
  7. Close the request
  8. Open the request again
  9. Notice that the request is in a modified state (circle on header) and that Content-Type has re-appeared. This is a bug - Content-Type is not applicable to GET requests and should not be auto-added.

Let me know if you are able to reproduce.

Thanks,
Troy

Hey @troylatchman

I was able to reproduce this, and have identified this as a bug in the latest 6.4.1 version.
Will be pushing out a fix for this asap.

I’m happy you were able to re-produce the issue!

Another observation: brand new requests that are created and saved today do not face this issue.

Looking forward to the fix.
Thanks so much @sujayvenaik!

-Troy

Here some more info/observation.
The new/rewritten from scratch GET that works has different info in the “body” in the project export. I’ve cut it down to the minimal stuff below. I “suspect” that maybe this happened when a test was copied & modified?

In any case, is there a way to correct it within Postman or do we have to recreate all GET tests that have this issue?

GOOD CASE
“body”: {
“mode”: “raw”,
“raw”: “”
},

BAD CASE
“body”: {
“mode”: “urlencoded”,
“urlencoded”: [
{ “key”: “X-account-number”, “value”: “123456”, “type”: “text” },
{ “key”: “X-account-type”, “value”: “Credit”, “type”: “text” },
{ “key”: “Authorization”, “value”: “Bearer AAEgZDg0ZDk1OTU5NTgzNDI0M2JlOWVkMjAzM2Y5ZGYwY2Q-wuFlQKfSBmE4u7VlpNm73RXU4IHOUJDaQZoAT8qvDy009fv9aPScVTRVoVK20fe4J-kIguB7eMWKNQ29F5_w9nCaDegsLTBWHYbOCUYOpNiNQjXfZyotsdsmfsEoD_8\n”, “type”: “text” }

@mer2018 @troylatchman

For all GET requests having this issue, a workaround can be:

  1. Change the request method to POST
  2. Change the body type to form-data in the Body tab
  3. Switch back to GET
  4. Make sure Content-Type header is removed
  5. Save the request.

After this Postman would no longer auto add Content-Type headers for GET requests.

Also, we have started work on Custom Request Methods and better handling for body for all request methods including GET. This will give more visibility on the actual stored body for the requests.

Hey @troylatchman @mer2018

We have released a fix for this issue.
Please update the app to the latest 6.4.2 version.

Thanks again for writing in and reporting this issue.

Sujay!!! Thanks so much!
Updated this morning & it’s been working like a champ.
Thanks again for such a quick & painless turnaround. I couldn’t believe this was waiting on me this morning. It saved me a ton of time & hassle.
Postman ROCKS!!!
You can close this ticket.

  • happy camper
2 Likes

Thank You!! This helped me solve an issue with Post and Content-Type stubbornly set to application/xml when I needed text/xml. Once I set the method option to Get and then added my own Content-Type, I noticed that Postman woon;t add the default COntent-Type. I then set the method to Post again a,d sent my request and it worked with 200 return code!