Fixed
Status Update
Comments
ra...@chromium.org <ra...@chromium.org> #2
[Empty comment from Monorail migration]
ca...@chromium.org <ca...@chromium.org> #3
[Empty comment from Monorail migration]
dg...@chromium.org <dg...@chromium.org> #4
[Empty comment from Monorail migration]
al...@chromium.org <al...@chromium.org> #5
[Empty comment from Monorail migration]
bt...@gmail.com <bt...@gmail.com> #6
I just encountered this. The character "Ã" got turned into \xc3 (valid Latin-1) instead of \xc3\x83 (valid UTF-8). The result is that "copy as curl" cannot be used to easily debug UTF-8 issues.
Wireshark verified that the original request was correct and the curl version was not.
Wireshark verified that the original request was correct and the curl version was not.
sj...@gmail.com <sj...@gmail.com> #7
Working on linux (Ubuntu 16.04 with Chrome version 56.0.2924.87 (64-bit)) and "copy as cURL" export data in Latin-1 instead of UTF-8 which is an issue.
pf...@chromium.org <pf...@chromium.org> #8
[Empty comment from Monorail migration]
bu...@chromium.org <bu...@chromium.org> #9
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/387f83205e24597cbaaf7ea96e6456583d0d5e59
commit 387f83205e24597cbaaf7ea96e6456583d0d5e59
Author: Erik Luo <luoe@chromium.org>
Date: Tue Aug 21 05:52:22 2018
DevTools: fix encoding for Copy as cURL
Before, the 'Copy as cURL' option would escape all characters outside
of a limited range [\x20-\x7e] with ANSI-C `\u` or `\x`. This caused
problems because `\x` does not properly encode Unicode chars outside
of the range (e.g. latin, CJK, emoji).
Instead, this CL treats control codes (C0, C1 sets) as the only
characters that need `\u` escaping, while everything else (except
single quote, backslash, newline) is not escaped.
Bug: 578054
Change-Id: I47301014ebe394bd02eb9f6c60108f4962f331ca
Reviewed-on:https://chromium-review.googlesource.com/1155924
Reviewed-by: Joel Einbinder <einbinder@chromium.org>
Reviewed-by: Andrey Lushnikov <lushnikov@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584664}
[modify]https://crrev.com/387f83205e24597cbaaf7ea96e6456583d0d5e59/third_party/WebKit/LayoutTests/http/tests/devtools/copy-network-request-expected.txt
[modify]https://crrev.com/387f83205e24597cbaaf7ea96e6456583d0d5e59/third_party/blink/renderer/devtools/front_end/network/NetworkLogView.js
commit 387f83205e24597cbaaf7ea96e6456583d0d5e59
Author: Erik Luo <luoe@chromium.org>
Date: Tue Aug 21 05:52:22 2018
DevTools: fix encoding for Copy as cURL
Before, the 'Copy as cURL' option would escape all characters outside
of a limited range [\x20-\x7e] with ANSI-C `\u` or `\x`. This caused
problems because `\x` does not properly encode Unicode chars outside
of the range (e.g. latin, CJK, emoji).
Instead, this CL treats control codes (C0, C1 sets) as the only
characters that need `\u` escaping, while everything else (except
single quote, backslash, newline) is not escaped.
Bug: 578054
Change-Id: I47301014ebe394bd02eb9f6c60108f4962f331ca
Reviewed-on:
Reviewed-by: Joel Einbinder <einbinder@chromium.org>
Reviewed-by: Andrey Lushnikov <lushnikov@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584664}
[modify]
[modify]
is...@google.com <is...@google.com> #11
This issue was migrated from crbug.com/chromium/578054?no_tracker_redirect=1
[Monorail components added to Component Tags custom field.]
[Monorail components added to Component Tags custom field.]
Description
Steps to reproduce the problem:
1. POST/PUT data using XHR that includes a body with utf-8 characters
2. Observe that the server receives properly encoded utf-8 characters (
3. Now, copy the same successful request using copy as cURL and run the request using curl
Use the following code to reproduce:
What is the expected behavior?
The server should receive properly encoded utf-8 characters
What went wrong?
The server receives incorrectly encoded characters, seemingly in windows-1252
This results in different behavior between the xhr-requests in the browser and the ones executed with curl, resulting in painful debugging of encoding issues.
Did this work before? N/A
Chrome version: 49.0.2622.0 Channel: canary
OS Version: OS X 10.11.2
Flash Version: Shockwave Flash 20.0 r0
The copied-as-curl string (
Chromium should either not convert the utf-8 characters to escape sequences, or at least convert them into proper utf-8 escape sequences (starting with \u)