From 965bd6b2adad5c4f78f970bc5168a04820640d9f 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 3203a8c310d76..caa939a5bcacb 100644 --- a/docs/reference/migration/migrate_8_0/rest-api-changes.asciidoc +++ b/docs/reference/migration/migrate_8_0/rest-api-changes.asciidoc @@ -1140,4 +1140,21 @@ 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 +---- +==== //end::notable-breaking-changes[]