Set Content-Type to application/json; charset=UTF-8

[chrstophg]

Hey!
Currently the Content-Type header is set to text/plain, like here for the batch calls. Since we're sending JSON, should this be updated to application/json; charset=UTF-8, or is there any reason I'm not aware of to use text/plain?

[silesky]

Hey @chrstophg, it's because that type still allowed for "Simple CORS", and our RPC api didn't really care as it parses everything as JSON.

I'm not sure if the batching API supports CORS today, I think so but would need to check -- the default tracking API (/t) does as of a couple years ago, but we still may want to use text/plain as CORS introduces the modest overhead of preflight requests.

Also, utf charset thing is not needed AFAIK, JSON is by default utf-8 :-)

Is there a particular reason you care about the content type?

[chrstophg]

We're setting up a backend proxy for events, and text/plain is currently rejected by my backend. I'm checking with the teams on our side as well to relax this requirement.

Thanks for the explanation 👍 .

[chrstophg]

Would you be open to allow custom headers to be passed to the fetch request in the segment.io integration object? I am happy to work on this and open a PR if so.

[silesky]

@chrstophg this isn't something we support at the moment unfortunately, and we probably would want to implement this ourselves by supporting more client options or a custom fetch implementation. We typically would create a spec, but very short of resources.

This is tracked in #392 FYI

ATM, the only workaround would be if you could monkey patch window.fetch on your end.