Running an API, if I correct a content-type header will that break things for customers?

We're running an API with quite a few people using it. Due to some legacy clumsiness on my part, one of the endpoints is returning the wrong content-type header, js when it should be json. My question is, if we fix this by swapping to return the correct value, how badly could it mess things up for our existing customers? Or to put it another way, would you expect many different HTTP client libraries to throw fatal errors when seeing such a change?

We're trying to decide if this is a change which we can just go ahead and make without sweating it too much, or we should carefully email all users and announce a multi-year deprecation period ...or something in between.

It probably depends a bit on what kind of different HTTP clients are in use, so I took a look at user agents. Answer: a lot of different ones! Here's some of the top ones:

"okhttp/3.2.0", "python-requests/2.10.0", "Ruby", "python-requests/2.7.0", "Mozilla/5.0", "Java/1.8.0_91", "python-requests/2.4.3", "okhttp/3.3.0", "Lucee", "Dalvik/2.1.0", "Google-HTTP-Java-Client/1.21.0", "PHP_appname", "NativeHost", "Java/1.7.0_67", "Apache-HttpClient/UNAVAILABLE", "Dalvik/1.6.0", "Web-sniffer/1.1.0", "unirest-objc/1.1"

Various different mobile and server side language libraries. Mostly not browsers running javascript, but some of those too.

Most people don't seem to notice that the content-type is wrong, but every now and then a new support request pops up complaining about this issue, so we'd like to fix it.

how badly could it mess things up for our existing customers?

It could completely sink their battleships if they've written code that relies on this Content-Type being incorrect.

I would not expect the libraries to throw errors, but I expect that in some cases strict libraries have had their behavior overridden to handle the incorrect MIME type.

If your API has a version/revision value in a request field somewhere, raise it, and in the new version return the correct type but continue to return the incorrect type in the older versions. If you don't have such a request field, now is a good time to add one.

Would you expect many different HTTP client libraries to throw fatal errors when seeing such a change?

No. Every HTTP client library I'm familiar with will ignore the content-type header unless the programmer specifically reads that header and does something with it. I can imagine a library where the content-type: application/json automatically causes a json parser to get involved but I don't know of any case where that actually happens.

Most people don't seem to notice that the content-type is wrong, but every now and then a new support request pops up complaining about this issue, so we'd like to fix it.

How did they notice the incorrect header? It might be worth looking at that, because if the incorrect header was actually causing them problems they clearly weren't just ignoring it, and they might have problems if it is fixed.