Sending unwanted Content-Type text/plain with binary uploads

[mumrah]

1. Postman Version: 4.9.1
2. App (Chrome app or Mac app): Mac app
3. OS details: 10.11.6
4. Is the Interceptor on and enabled in the app: No
5. Did you encounter this recently, or has this bug always been there: Unsure
6. Expected behaviour: Should send no Content-Type if none is specified (or application/octet-stream in the case of binary POST body)
7. Console logs (http://blog.getpostman.com/2014/01/27/enabling-chrome-developer-tools-inside-postman/ for the Chrome App, View->Toggle Dev Tools for the Mac app):
8. Screenshots (if applicable)

• Construct a POST request with a binary body (say, a zip file)
• Don't set any Content-Type
• Observe that text/plain is sent instead of nothing

I suspect this might be a problem of the default Content-Type from the "raw" body carrying over when switching to a "binary" body. The problem is solved by setting an explicit Content-Type header

[mumrah]

Actually, I just confirmed my suspicion. If I switch to a "raw" body and select "JSON (application/json)", then switch back to "binary", the server receives "application/json" now

[a85]

We'll fix this issue around setting the Content-Type header automatically in a future version. For now, we recommend setting the Content-Type explicitly.

[ttop]

Agreed, I just spent a bunch of time troubleshooting an issue where I was trying to test an app with a POST with no Content-Type specified but it appeared as if a Content-Type header was being set to 'text/plain' even though my Postman config had no such header defined. I thought there was a bug in the app code since nothing in Postman indicated it was sending this header. Eventually by debugging the app I found that the header was being sent by Postman.

Based on the above if I explicitly set the Content-Type header with no value specified, but even this included a Content-Type header in the payload, just with no value. There doesn't appear to be a way at present to force it to not automatically add the header.

This page seems to imply it's a feature!

Note about Headers: When you are sending requests through the HTTP protocol, your server might expect a Content-Type header. The Content-Type header allows the server to parse the body properly. For form-data and urlencoded body types, Postman automatically attaches the correct Content-Type header so you don’t have to set it. The raw mode header is set when you select the formatting type. If you manually use a Content-Type header, that value takes precedence over what Postman sets. Postman does not set any header type for the binary body type.

But I say this is unexpected and undesirable behavior as it basically makes Postman incapable of posting a payload without that header, and at least in my case this is exactly what I was trying to test. I think perhaps this feature was misguided, but maybe others like it. It would be nice to be able to disable this functionality.

[Luthien-in-edhil]

But I say this is unexpected and undesirable behavior as it basically makes Postman incapable of posting a payload without that header, and at least in my case this is exactly what I was trying to test. I think perhaps this feature was misguided, but maybe others like it. It would be nice to be able to disable this functionality.

Copy that. I need to be able to test the scenario where no Content-Type header is given.

[rebeccapowell]

I'd like to second this. This is an error condition I need to test.

[bjarkebm]

While testing Apaches Tika server, I ran into this problem, namely that a Content-Type: text/plain is sent along.
One of the strong features of Tika is to figure out what kind of content it is being sent. This happens unless a Content-Type header is sent, so it is rather unfortunate that Postman sends it along.
If I have to set the Content-Type myself, it defeats my purpose of using Tika in the first place.

[andreacab]

I am having the same issue using postman v 6.7.4, is it resolved? What's the status?
I filed an issue on SO here. Help is greatly appreciated.

[andreacab]

@a85 what if you need no Content-Type, as with aws S3 pre-signed urls...

[SattaiLanfear]

It seems strange to close the issue before the issue is actually resolved, and likely to make the problem go forgotten indefinitely.

I ran into problems with this myself.