fix: decode response body as UTF-8 when no charset specified in DevToolsPlugin#1570
Merged
garrytrinder merged 3 commits intodotnet:mainfrom Mar 2, 2026
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates DevToolsPlugin’s request/response body decoding so that when Content-Type omits a charset, bodies are decoded as UTF-8 instead of relying on the proxy library’s ISO-8859-1 default, fixing garbled Unicode in the DevTools inspector (issue #1566).
Changes:
- Introduced a
GetBodyStringhelper to decode raw body bytes as UTF-8 when no charset is specified. - Switched DevTools request
PostDataand text response body handling to use the new helper.
garrytrinder
approved these changes
Mar 2, 2026
Contributor
garrytrinder
left a comment
There was a problem hiding this comment.
Built and tested in detached mode. Clean startup, no errors. The GetBodyString method correctly parses charset from Content-Type, falls back to UTF-8 for modern web content (per RFC 7231/8259) instead of the library default ISO-8859-1. Applied consistently in both request and response paths. Good comment explaining the rationale. LGTM.
…olsPlugin When the Content-Type header doesn't include a charset (e.g. 'application/json' vs 'application/json; charset=utf-8'), the underlying proxy library defaults to ISO-8859-1 per the obsolete RFC 2616. This causes Unicode characters to appear garbled in the DevTools inspector. Default to UTF-8 decoding when no charset is specified, which aligns with modern standards (RFC 7231, RFC 8259). Fixes dotnet#1566 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Use System.Net.Mime.ContentType to parse the charset from Content-Type headers instead of manual string splitting. This handles quoted charsets (e.g. charset="utf-8") and gracefully falls back to UTF-8 for malformed headers or unsupported charsets. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
4b19292 to
d28b372
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When the
Content-Typeheader doesn't include a charset (e.g.application/jsoninstead ofapplication/json; charset=utf-8), the underlying proxy library defaults to ISO-8859-1 per the obsolete RFC 2616. This causes Unicode characters (e.g. ``) to appear garbled in the DevTools inspector.Fix
Default to UTF-8 when no charset is specified in the
Content-Typeheader, aligning with modern standards:When a charset is explicitly specified, we honor it.
Changes
GetBodyStringhelper that decodes raw response bytes using UTF-8 when no charset is present, or uses the specified charset otherwisePostData) and response body in DevToolsPluginFixes #1566