From 020801c945374b669b6680de7879bd70874c54e8 Mon Sep 17 00:00:00 2001
From: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
Date: Tue, 19 Nov 2024 12:29:33 -0500
Subject: [PATCH] [DOCS] document `Content-Type` breaking change from 8.0
 (#116845)

(cherry picked from commit fc987d81fe27666286e0d28487a841a563212f55)
---
 .../migrate_8_0/rest-api-changes.asciidoc       | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/docs/reference/migration/migrate_8_0/rest-api-changes.asciidoc b/docs/reference/migration/migrate_8_0/rest-api-changes.asciidoc
index 99c09b9b05385..85fc4160ea071 100644
--- a/docs/reference/migration/migrate_8_0/rest-api-changes.asciidoc
+++ b/docs/reference/migration/migrate_8_0/rest-api-changes.asciidoc
@@ -1136,3 +1136,20 @@ for both cases.
 *Impact* +
 To detect a server timeout, check the `timed_out` field of the JSON response.
 ====
+
+.The `Content-Type` response header no longer specifies the charset.
+[%collapsible]
+====
+*Details* +
+The `Content-Type` response header no longer specifies the charset. This information is not required when transferring JSON data, because JSON text will always be encoded in Unicode, with UTF-8 being the default encoding.
+
+*Impact* +
+Some applications and utilities, such as PowerShell's https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-restmethod[Invoke-RestMethod], must receive charset information to display data correctly. If your application or utility relies on charset information in the `Content-Type` response header, UTF-8 encoded characters will be rendered incorrectly in the response body.
+
+As a workaround, to render non-ASCII characters, include an HTTP `Accept` header in your requests, specifying the charset: 
+
+[source,sh]
+----
+Accept: application/json; charset=utf-8
+----
+====
\ No newline at end of file