curl/tests/data/test268
Emanuele Torre 6c7da81561
tool_writeout_json: fix JSON encoding of non-ascii bytes
char variables if unspecified can be either signed or unsigned depending
on the platform according to the C standard; in most platforms, they are
signed.

This meant that the  *i<32  waas always true for bytes with the top bit
set. So they were always getting encoded as \uXXXX, and then since they
were also signed negative, they were getting extended with 1s causing
'\xe2' to be expanded to \uffffffe2, for example:

  $ curl --variable 'v=“' --expand-write-out '{{v:json}}\n' file:///dev/null
  \uffffffe2\uffffff80\uffffff9c

I fixed this bug by making the code use explicitly unsigned char*
variables instead of char* variables.

Test 268 verifies

Reported-by: iconoclasthero
Closes #12434
2023-12-01 10:39:13 +01:00

60 lines
980 B
Plaintext

<testcase>
<info>
<keywords>
HTTP
variables
</keywords>
</info>
#
# Server-side
<reply>
<data crlf="yes">
HTTP/1.1 200 OK
Date: Tue, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Last-Modified: Tue, 13 Jun 2000 12:10:00 GMT
ETag: "21025-dc7-39462498"
Accept-Ranges: bytes
Content-Length: 6
Connection: close
Content-Type: text/html
Funny-head: yesyes
-foo-
</data>
</reply>
#
# Client-side
<client>
<server>
http
</server>
<name>
JSON encoding of unicode string
</name>
<file name="%LOGDIR/junk" nonewline="yes">
%hex[%e2%80%9c]hex%
</file>
<command>
http://%HOSTIP:%HTTPPORT/%TESTNUMBER --variable hello@%LOGDIR/junk --expand-data {{hello:json}}
</command>
</client>
#
# Verify data after the test has been "shot"
<verify>
<protocol crlf="yes" nonewline="yes">
POST /%TESTNUMBER HTTP/1.1
Host: %HOSTIP:%HTTPPORT
User-Agent: curl/%VERSION
Accept: */*
Content-Length: 3
Content-Type: application/x-www-form-urlencoded
%hex[%e2%80%9c]hex%
</protocol>
</verify>
</testcase>