There is currently no ability to remove a Content-Type header

[klardotsh]

Defaults currently uses the following logic to extend the options object:

function defaults (target, obj) {
    for (var prop in obj) target[prop] = target[prop] || obj[prop]
}

If you would prefer to not send a Content-Type at all, you'd not want it in the headers array (I don't believe fetch sets a Content-Type by default, if it does then my logic is wrong). By passing { 'Content-Type': undefined } into the fetchival options, it will hit the || logic of the extender, keeping the default header rather than removing the header as is the expected behavior.

The fix will be to forcibly set any "own properties" of the incoming object, even if they are not truthy.

[typicode]

Hi @iv597,

Thank you for the PR. I'm curious why you wouldn't want to send a Content-Type?
Actually, I've added these headers based on https://github.com/github/fetch#post-json

[klardotsh]

I'm not particularly saying you should negate either of those default headers. Definitely it's a Good Idea (TM) to be explicit in headers. However, I'm retrofitting fetch into an existing application at work which explicitly set contentType: false, on a jQuery.ajax() call, so I'm assuming there was some technical reason for that I haven't looked into.

I think making this disabling explicit (just as jQuery does) more or less solves all problems. The defaults will be there if you don't specify a Content-Type or Accept header, but you can explicitly remove them if your backend can't support it and/or the legacy code you're porting disabled them.

[klardotsh]

Any update on this?

[typicode]

Yes, sorry. I'll try to take care of it today or tomorrow.

[typicode]

When I google contentType: false, it seems like it's mostly used for sending files.
And for the moment, I prefer fetchival to stay a microlib focused only on JSON requests.

Except if I'm missing something, for edge-cases where fetchival doesn't work, I think that using directly the new fetch API can be fine.

[roccomuso]

This should be addressed, to have more control on headers sent.