tests/FILEFORMAT.md

   1 <!--
   2 Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
   3
   4 SPDX-License-Identifier: curl
   5 -->
   6
   7 # curl test suite file format
   8
   9 The curl test suite's file format is simple and extendable, closely resembling
  10 XML. All data for a single test case resides in a single ASCII file. Labels
  11 mark the beginning and the end of all sections, and each label must be written
  12 in its own line. Comments are either XML-style (enclosed with `<!--` and
  13 `-->`) or shell script style (beginning with `#`) and must appear on their own
  14 lines and not alongside actual test data. Most test data files are
  15 syntactically valid XML, although a few files are not (lack of support for
  16 character entities and the preservation of CR/LF characters at the end of
  17 lines are the biggest differences).
  18
  19 Each test case source exists as a file matching the format
  20 `tests/data/testNUM`, where `NUM` is the unique test number, and must begin
  21 with a `testcase` tag, which encompasses the remainder of the file.
  22
  23 # Preprocessing
  24
  25 When a test is to be executed, the source file is first preprocessed and
  26 variables are substituted by their respective contents and the output
  27 version of the test file is stored as `%LOGDIR/testNUM`. That version is what
  28 will be read and used by the test servers.
  29
  30 ## Base64 Encoding
  31
  32 In the preprocess stage, a special instruction can be used to have runtests.pl
  33 base64 encode a certain section and insert in the generated output file. This
  34 is in particular good for test cases where the test tool is expected to pass
  35 in base64 encoded content that might use dynamic information that is unique
  36 for this particular test invocation, like the server port number.
  37
  38 To insert a base64 encoded string into the output, use this syntax:
  39
  40     %b64[ data to encode ]b64%
  41
  42 The data to encode can then use any of the existing variables mentioned below,
  43 or even percent-encoded individual bytes. As an example, insert the HTTP
  44 server's port number (in ASCII) followed by a space and the hexadecimal byte
  45 9a:
  46
  47     %b64[%HTTPPORT %9a]b64%
  48
  49 ## Hexadecimal decoding
  50
  51 In the preprocess stage, a special instruction can be used to have runtests.pl
  52 generate a sequence of binary bytes.
  53
  54 To insert a sequence of bytes from a hex encoded string, use this syntax:
  55
  56     %hex[ %XX-encoded data to decode ]hex%
  57
  58 For example, to insert the binary octets 0, 1 and 255 into the test file:
  59
  60     %hex[ %00%01%FF ]hex%
  61
  62 ## Repeat content
  63
  64 In the preprocess stage, a special instruction can be used to have runtests.pl
  65 generate a repetitive sequence of bytes.
  66
  67 To insert a sequence of repeat bytes, use this syntax to make the `<string>`
  68 get repeated `<number>` of times. The number has to be 1 or larger and the
  69 string may contain `%HH` hexadecimal codes:
  70
  71     %repeat[<number> x <string>]%
  72
  73 For example, to insert the word hello 100 times:
  74
  75     %repeat[100 x hello]%
  76
  77 ## Conditional lines
  78
  79 Lines in the test file can be made to appear conditionally on a specific
  80 feature (see the "features" section below) being set or not set. If the
  81 specific feature is present, the following lines will be output, otherwise it
  82 outputs nothing, until a following else or `endif` clause. Like this:
  83
  84     %if brotli
  85     Accept-Encoding
  86     %endif
  87
  88 It can also check for the inverse condition, so if the feature is *not* set by
  89 the use of an exclamation mark:
  90
  91     %if !brotli
  92     Accept-Encoding: not-brotli
  93     %endif
  94
  95 You can also make an "else" clause to get output for the opposite condition,
  96 like:
  97
  98     %if brotli
  99     Accept-Encoding: brotli
 100     %else
 101     Accept-Encoding: nothing
 102     %endif
 103
 104 Nested conditions are supported.
 105
 106 # Variables
 107
 108 When the test is preprocessed, a range of "variables" in the test file will be
 109 replaced by their content at that time.
 110
 111 Available substitute variables include:
 112
 113 - `%CLIENT6IP` - IPv6 address of the client running curl
 114 - `%CLIENTIP` - IPv4 address of the client running curl
 115 - `%CURL` - Path to the curl executable
 116 - `%FILE_PWD` - Current directory, on Windows prefixed with a slash
 117 - `%FTP6PORT` - IPv6 port number of the FTP server
 118 - `%FTPPORT` - Port number of the FTP server
 119 - `%FTPSPORT` - Port number of the FTPS server
 120 - `%FTPTIME2` - Timeout in seconds that should be just sufficient to receive a
 121   response from the test FTP server
 122 - `%FTPTIME3` - Even longer than `%FTPTIME2`
 123 - `%GOPHER6PORT` - IPv6 port number of the Gopher server
 124 - `%GOPHERPORT` - Port number of the Gopher server
 125 - `%GOPHERSPORT` - Port number of the Gophers server
 126 - `%HOST6IP` - IPv6 address of the host running this test
 127 - `%HOSTIP` - IPv4 address of the host running this test
 128 - `%HTTP6PORT` - IPv6 port number of the HTTP server
 129 - `%HTTPPORT` - Port number of the HTTP server
 130 - `%HTTP2PORT` - Port number of the HTTP/2 server
 131 - `%HTTPSPORT` - Port number of the HTTPS server
 132 - `%HTTPSPROXYPORT` - Port number of the HTTPS-proxy
 133 - `%HTTPTLS6PORT` - IPv6 port number of the HTTP TLS server
 134 - `%HTTPTLSPORT` - Port number of the HTTP TLS server
 135 - `%HTTPUNIXPATH` - Path to the Unix socket of the HTTP server
 136 - `%SOCKSUNIXPATH` - Path to the Unix socket of the SOCKS server
 137 - `%IMAP6PORT` - IPv6 port number of the IMAP server
 138 - `%IMAPPORT` - Port number of the IMAP server
 139 - `%LOGDIR` - Log directory relative to %PWD
 140 - `%MQTTPORT` - Port number of the MQTT server
 141 - `%TELNETPORT` - Port number of the telnet server
 142 - `%NOLISTENPORT` - Port number where no service is listening
 143 - `%POP36PORT` - IPv6 port number of the POP3 server
 144 - `%POP3PORT` - Port number of the POP3 server
 145 - `%POSIX_PWD` - Current directory somewhat mingw friendly
 146 - `%PROXYPORT` - Port number of the HTTP proxy
 147 - `%PWD` - Current directory
 148 - `%RTSP6PORT` - IPv6 port number of the RTSP server
 149 - `%RTSPPORT` - Port number of the RTSP server
 150 - `%SMBPORT` - Port number of the SMB server
 151 - `%SMBSPORT` - Port number of the SMBS server
 152 - `%SMTP6PORT` - IPv6 port number of the SMTP server
 153 - `%SMTPPORT` - Port number of the SMTP server
 154 - `%SOCKSPORT` - Port number of the SOCKS4/5 server
 155 - `%SRCDIR` - Full path to the source dir
 156 - `%SSHPORT` - Port number of the SCP/SFTP server
 157 - `%SSHSRVMD5` - MD5 of SSH server's public key
 158 - `%SSHSRVSHA256` - SHA256 of SSH server's public key
 159 - `%SSH_PWD` - Current directory friendly for the SSH server
 160 - `%TESTNUMBER` - Number of the test case
 161 - `%TFTP6PORT` - IPv6 port number of the TFTP server
 162 - `%TFTPPORT` - Port number of the TFTP server
 163 - `%USER` - Login ID of the user running the test
 164 - `%VERSION` - the full version number of the tested curl
 165
 166 # `<testcase>`
 167
 168 Each test is always specified entirely within the `testcase` tag. Each test
 169 case is split up in four main sections: `info`, `reply`, `client` and
 170 `verify`.
 171
 172 - **info** provides information about the test case
 173
 174 - **reply** is used for the server to know what to send as a reply for the
 175 requests curl sends
 176
 177 - **client** defines how the client should behave
 178
 179 - **verify** defines how to verify that the data stored after a command has
 180 been run ended up correct
 181
 182 Each main section has a number of available subsections that can be specified,
 183 that will be checked/used if specified.
 184
 185 ## `<info>`
 186
 187 ### `<keywords>`
 188 A newline-separated list of keywords describing what this test case uses and
 189 tests. Try to use already used keywords. These keywords will be used for
 190 statistical/informational purposes and for choosing or skipping classes of
 191 tests. Keywords must begin with an alphabetic character, `-`, `[` or `{` and
 192 may actually consist of multiple words separated by spaces which are treated
 193 together as a single identifier. Most keywords are only there to provide a way
 194 for users to skip certain classes of tests, if desired, but a few are treated
 195 specially by the test harness or build system.
 196
 197 When using curl built with Hyper, the keywords must include `HTTP` or `HTTPS`
 198 for 'hyper mode' to kick in and make line ending checks work for tests.
 199
 200 When running a unit test and the keywords include `unittest`, the `<tool>`
 201 section can be left empty to use the standard unit test tool name `unitN` where
 202 `N` is the test number.
 203
 204 The `text-ci` make target automatically skips test with the `flaky` keyword.
 205
 206 Tests that have strict timing dependencies have the `timing-dependent` keyword.
 207 These are intended to eventually be treated specially on CI builds which are
 208 often run on overloaded machines with unpredictable timing.
 209
 210 ## `<reply>`
 211
 212 ### `<data [nocheck="yes"] [sendzero="yes"] [base64="yes"] [hex="yes"] [nonewline="yes"] [crlf="yes"]>`
 213
 214 data to be sent to the client on its request and later verified that it
 215 arrived safely. Set `nocheck="yes"` to prevent the test script from verifying
 216 the arrival of this data.
 217
 218 If the data contains `swsclose` anywhere within the start and end tag, and
 219 this is an HTTP test, then the connection will be closed by the server after
 220 this response is sent. If not, the connection will be kept persistent.
 221
 222 If the data contains `swsbounce` anywhere within the start and end tag, the
 223 HTTP server will detect if this is a second request using the same test and
 224 part number and will then increase the part number with one. This is useful
 225 for auth tests and similar.
 226
 227 `sendzero=yes` means that the (FTP) server will "send" the data even if the
 228 size is zero bytes. Used to verify curl's behavior on zero bytes transfers.
 229
 230 `base64=yes` means that the data provided in the test-file is a chunk of data
 231 encoded with base64. It is the only way a test case can contain binary
 232 data. (This attribute can in fact be used on any section, but it doesn't make
 233 much sense for other sections than "data").
 234
 235 `hex=yes` means that the data is a sequence of hex pairs. It will get decoded
 236 and used as "raw" data.
 237
 238 `nonewline=yes` means that the last byte (the trailing newline character)
 239 should be cut off from the data before sending or comparing it.
 240
 241 `crlf=yes` forces *header* newlines to become CRLF even if not written so in
 242 the source file. Note that this makes runtests.pl parse and "guess" what is a
 243 header and what is not in order to apply the CRLF line endings appropriately.
 244
 245 For FTP file listings, the `<data>` section will be used *only* if you make
 246 sure that there has been a CWD done first to a directory named `test-[NUM]`
 247 where `NUM` is the test case number. Otherwise the ftp server can't know from
 248 which test file to load the list content.
 249
 250 ### `<dataNUM [crlf="yes"]>`
 251
 252 Send back this contents instead of the `<data>` one. The `NUM` is set by:
 253
 254  - The test number in the request line is >10000 and this is the remainder
 255    of [test case number]%10000.
 256  - The request was HTTP and included digest details, which adds 1000 to `NUM`
 257  - If an HTTP request is NTLM type-1, it adds 1001 to `NUM`
 258  - If an HTTP request is NTLM type-3, it adds 1002 to `NUM`
 259  - If an HTTP request is Basic and `NUM` is already >=1000, it adds 1 to `NUM`
 260  - If an HTTP request is Negotiate, `NUM` gets incremented by one for each
 261    request with Negotiate authorization header on the same test case.
 262
 263 Dynamically changing `NUM` in this way allows the test harness to be used to
 264 test authentication negotiation where several different requests must be sent
 265 to complete a transfer. The response to each request is found in its own data
 266 section. Validating the entire negotiation sequence can be done by specifying
 267 a `datacheck` section.
 268
 269 ### `<connect>`
 270 The connect section is used instead of the 'data' for all CONNECT
 271 requests. The remainder of the rules for the data section then apply but with
 272 a connect prefix.
 273
 274 ### `<socks>`
 275 Address type and address details as logged by the SOCKS proxy.
 276
 277 ### `<datacheck [mode="text"] [nonewline="yes"] [crlf="yes"]>`
 278 if the data is sent but this is what should be checked afterwards. If
 279 `nonewline=yes` is set, runtests will cut off the trailing newline from the
 280 data before comparing with the one actually received by the client.
 281
 282 Use the `mode="text"` attribute if the output is in text mode on platforms
 283 that have a text/binary difference.
 284
 285 ### `<datacheckNUM [nonewline="yes"] [mode="text"] [crlf="yes"]>`
 286 The contents of numbered `datacheck` sections are appended to the non-numbered
 287 one.
 288
 289 ### `<size>`
 290 number to return on a ftp SIZE command (set to -1 to make this command fail)
 291
 292 ### `<mdtm>`
 293 what to send back if the client sends a (FTP) `MDTM` command, set to -1 to
 294 have it return that the file doesn't exist
 295
 296 ### `<postcmd>`
 297 special purpose server-command to control its behavior *after* the
 298 reply is sent
 299 For HTTP/HTTPS, these are supported:
 300
 301 `wait [secs]` - Pause for the given time
 302
 303 ### `<servercmd>`
 304 Special-commands for the server.
 305
 306 The first line of this file will always be set to `Testnum [number]` by the
 307 test script, to allow servers to read that to know what test the client is
 308 about to issue.
 309
 310 #### For FTP/SMTP/POP/IMAP
 311
 312 - `REPLY [command] [return value] [response string]` - Changes how the server
 313   responds to the [command]. [response string] is evaluated as a perl string,
 314   so it can contain embedded \r\n, for example. There's a special [command]
 315   named "welcome" (without quotes) which is the string sent immediately on
 316   connect as a welcome.
 317 - `REPLYLF` (like above but sends the response terminated with LF-only and not
 318    CRLF)
 319 - `COUNT [command] [num]` - Do the `REPLY` change for `[command]` only `[num]`
 320   times and then go back to the built-in approach
 321 - `DELAY [command] [secs]` - Delay responding to this command for the given
 322   time
 323 - `RETRWEIRDO` - Enable the "weirdo" RETR case when multiple response lines
 324    appear at once when a file is transferred
 325 - `RETRNOSIZE` - Make sure the RETR response doesn't contain the size of the
 326   file
 327 - `RETRSIZE [size]` - Force RETR response to contain the specified size
 328 - `NOSAVE` - Don't actually save what is received
 329 - `SLOWDOWN` - Send FTP responses with 0.01 sec delay between each byte
 330 - `PASVBADIP` - makes PASV send back an illegal IP in its 227 response
 331 - `CAPA [capabilities]` - Enables support for and specifies a list of space
 332    separated capabilities to return to the client for the IMAP `CAPABILITY`,
 333    POP3 `CAPA` and SMTP `EHLO` commands
 334 - `AUTH [mechanisms]` - Enables support for SASL authentication and specifies
 335    a list of space separated mechanisms for IMAP, POP3 and SMTP
 336 - `STOR [msg]` respond with this instead of default after `STOR`
 337
 338 #### For HTTP/HTTPS
 339
 340 - `auth_required` if this is set and a POST/PUT is made without auth, the
 341   server will NOT wait for the full request body to get sent
 342 - `delay: [msecs]` - delay this amount after connection
 343 - `idle` - do nothing after receiving the request, just "sit idle"
 344 - `stream` - continuously send data to the client, never-ending
 345 - `writedelay: [msecs]` delay this amount between reply packets
 346 - `skip: [num]` - instructs the server to ignore reading this many bytes from
 347   a PUT or POST request
 348 - `rtp: part [num] channel [num] size [num]` - stream a fake RTP packet for
 349   the given part on a chosen channel with the given payload size
 350 - `connection-monitor` - When used, this will log `[DISCONNECT]` to the
 351   `server.input` log when the connection is disconnected.
 352 - `upgrade` - when an HTTP upgrade header is found, the server will upgrade to
 353   http2
 354 - `swsclose` - instruct server to close connection after response
 355 - `no-expect` - don't read the request body if Expect: is present
 356
 357 #### For TFTP
 358 `writedelay: [secs]` delay this amount between reply packets (each packet
 359   being 512 bytes payload)
 360
 361 ## `<client>`
 362
 363 ### `<server>`
 364 What server(s) this test case requires/uses. Available servers:
 365
 366 - `dict`
 367 - `file`
 368 - `ftp`
 369 - `ftp-ipv6`
 370 - `ftps`
 371 - `gopher`
 372 - `gopher-ipv6`
 373 - `gophers`
 374 - `http`
 375 - `http/2`
 376 - `http-ipv6`
 377 - `http-proxy`
 378 - `https`
 379 - `https-proxy`
 380 - `httptls+srp`
 381 - `httptls+srp-ipv6`
 382 - `http-unix`
 383 - `imap`
 384 - `mqtt`
 385 - `none`
 386 - `pop3`
 387 - `rtsp`
 388 - `rtsp-ipv6`
 389 - `scp`
 390 - `sftp`
 391 - `smb`
 392 - `smtp`
 393 - `socks4`
 394 - `socks5`
 395 - `socks5unix`
 396 - `telnet`
 397 - `tftp`
 398
 399 Give only one per line. This subsection is mandatory (use `none` if no servers
 400 are required). Servers that require a special server certificate can have the
 401 PEM certificate file name (found in the `certs` directory) appended to the
 402 server name separated by a space.
 403
 404 ### `<features>`
 405 A list of features that MUST be present in the client/library for this test to
 406 be able to run. If a required feature is not present then the test will be
 407 SKIPPED.
 408
 409 Alternatively a feature can be prefixed with an exclamation mark to indicate a
 410 feature is NOT required. If the feature is present then the test will be
 411 SKIPPED.
 412
 413 Features testable here are:
 414
 415 - `alt-svc`
 416 - `bearssl`
 417 - `brotli`
 418 - `c-ares`
 419 - `CharConv`
 420 - `cookies`
 421 - `crypto`
 422 - `debug`
 423 - `DoH`
 424 - `getrlimit`
 425 - `GnuTLS`
 426 - `GSS-API`
 427 - `h2c`
 428 - `headers-api`
 429 - `HSTS`
 430 - `HTTP-auth`
 431 - `http/2`
 432 - `http/3`
 433 - `https-proxy`
 434 - `hyper`
 435 - `idn`
 436 - `ipv6`
 437 - `Kerberos`
 438 - `large_file`
 439 - `large-time` (time_t is larger than 32 bit)
 440 - `ld_preload`
 441 - `libssh2`
 442 - `libssh`
 443 - `oldlibssh` (versions before 0.9.4)
 444 - `libz`
 445 - `manual`
 446 - `mbedtls`
 447 - `Mime`
 448 - `netrc`
 449 - `nghttpx`
 450 - `nghttpx-h3`
 451 - `NTLM`
 452 - `NTLM_WB`
 453 - `OpenSSL`
 454 - `parsedate`
 455 - `proxy`
 456 - `PSL`
 457 - `rustls`
 458 - `Schannel`
 459 - `sectransp`
 460 - `shuffle-dns`
 461 - `socks`
 462 - `SPNEGO`
 463 - `SSL`
 464 - `SSLpinning`
 465 - `SSPI`
 466 - `threaded-resolver`
 467 - `TLS-SRP`
 468 - `TrackMemory`
 469 - `typecheck`
 470 - `threadsafe`
 471 - `Unicode`
 472 - `unittest`
 473 - `unix-sockets`
 474 - `verbose-strings`
 475 - `wakeup`
 476 - `win32`
 477 - `wolfssh`
 478 - `wolfssl`
 479 - `xattr`
 480 - `zstd`
 481
 482 as well as each protocol that curl supports. A protocol only needs to be
 483 specified if it is different from the server (useful when the server is
 484 `none`).
 485
 486 ### `<killserver>`
 487 Using the same syntax as in `<server>` but when mentioned here these servers
 488 are explicitly KILLED when this test case is completed. Only use this if there
 489 is no other alternatives. Using this of course requires subsequent tests to
 490 restart servers.
 491
 492 ### `<precheck>`
 493 A command line that if set gets run by the test script before the test. If an
 494 output is displayed by the command or if the return code is non-zero, the test
 495 will be skipped and the (single-line) output will be displayed as reason for
 496 not running the test.
 497
 498 ### `<postcheck>`
 499 A command line that if set gets run by the test script after the test. If
 500 the command exists with a non-zero status code, the test will be considered
 501 to have failed.
 502
 503 ### `<tool>`
 504 Name of tool to invoke instead of "curl". This tool must be built and exist
 505 either in the `libtest/` directory (if the tool name starts with `lib`) or in
 506 the `unit/` directory (if the tool name starts with `unit`).
 507
 508 ### `<name>`
 509 Brief test case description, shown when the test runs.
 510
 511 ### `<setenv>`
 512     variable1=contents1
 513     variable2=contents2
 514
 515 Set the given environment variables to the specified value before the actual
 516 command is run. They are cleared again after the command has been run.
 517
 518 ### `<command [option="no-output/no-include/force-output/binary-trace"] [timeout="secs"][delay="secs"][type="perl/shell"]>`
 519 Command line to run.
 520
 521 Note that the URL that gets passed to the server actually controls what data
 522 that is returned. The last slash in the URL must be followed by a number. That
 523 number (N) will be used by the test-server to load test case N and return the
 524 data that is defined within the `<reply><data></data></reply>` section.
 525
 526 If there's no test number found above, the HTTP test server will use the
 527 number following the last dot in the given hostname (made so that a CONNECT
 528 can still pass on test number) so that "foo.bar.123" gets treated as test case
 529 123. Alternatively, if an IPv6 address is provided to CONNECT, the last
 530 hexadecimal group in the address will be used as the test number! For example
 531 the address "[1234::ff]" would be treated as test case 255.
 532
 533 Set `type="perl"` to write the test case as a perl script. It implies that
 534 there's no memory debugging and valgrind gets shut off for this test.
 535
 536 Set `type="shell"` to write the test case as a shell script. It implies that
 537 there's no memory debugging and valgrind gets shut off for this test.
 538
 539 Set `option="no-output"` to prevent the test script to slap on the `--output`
 540 argument that directs the output to a file. The `--output` is also not added
 541 if the verify/stdout section is used.
 542
 543 Set `option="force-output"` to make use of `--output` even when the test is
 544 otherwise written to verify stdout.
 545
 546 Set `option="no-include"` to prevent the test script to slap on the
 547 `--include` argument.
 548
 549 Set `option="binary-trace"` to use `--trace` instead of `--trace-ascii` for
 550 tracing. Suitable for binary-oriented protocols such as MQTT.
 551
 552 Set `timeout="secs"` to override default server logs advisor read lock
 553 timeout. This timeout is used by the test harness, once that the command has
 554 completed execution, to wait for the test server to write out server side log
 555 files and remove the lock that advised not to read them. The "secs" parameter
 556 is the not negative integer number of seconds for the timeout. This `timeout`
 557 attribute is documented for completeness sake, but is deep test harness stuff
 558 and only needed for singular and specific test cases. Avoid using it.
 559
 560 Set `delay="secs"` to introduce a time delay once that the command has
 561 completed execution and before the `<postcheck>` section runs. The "secs"
 562 parameter is the not negative integer number of seconds for the delay. This
 563 'delay' attribute is intended for specific test cases, and normally not
 564 needed.
 565
 566 ### `<file name="%LOGDIR/filename" [nonewline="yes"]>`
 567 This creates the named file with this content before the test case is run,
 568 which is useful if the test case needs a file to act on.
 569
 570 If `nonewline="yes"` is used, the created file will have the final newline
 571 stripped off.
 572
 573 ### `<stdin [nonewline="yes"]>`
 574 Pass this given data on stdin to the tool.
 575
 576 If `nonewline` is set, we will cut off the trailing newline of this given data
 577 before comparing with the one actually received by the client
 578
 579 ## `<verify>`
 580 ### `<errorcode>`
 581 numerical error code curl is supposed to return. Specify a list of accepted
 582 error codes by separating multiple numbers with comma. See test 237 for an
 583 example.
 584
 585 ### `<strip>`
 586 One regex per line that is removed from the protocol dumps before the
 587 comparison is made. This is useful to remove dependencies on dynamically
 588 changing protocol data such as port numbers or user-agent strings.
 589
 590 ### `<strippart>`
 591 One perl op per line that operates on the protocol dump. This is pretty
 592 advanced. Example: `s/^EPRT .*/EPRT stripped/`.
 593
 594 ### `<protocol [nonewline="yes"][crlf="yes"]>`
 595
 596 the protocol dump curl should transmit, if `nonewline` is set, we will cut off
 597 the trailing newline of this given data before comparing with the one actually
 598 sent by the client The `<strip>` and `<strippart>` rules are applied before
 599 comparisons are made.
 600
 601 `crlf=yes` forces the newlines to become CRLF even if not written so in the
 602 test.
 603
 604 ### `<proxy [nonewline="yes"][crlf="yes"]>`
 605
 606 The protocol dump curl should transmit to an HTTP proxy (when the http-proxy
 607 server is used), if `nonewline` is set, we will cut off the trailing newline
 608 of this given data before comparing with the one actually sent by the client
 609 The `<strip>` and `<strippart>` rules are applied before comparisons are made.
 610
 611 ### `<stderr [mode="text"] [nonewline="yes"]>`
 612 This verifies that this data was passed to stderr.
 613
 614 Use the mode="text" attribute if the output is in text mode on platforms that
 615 have a text/binary difference.
 616
 617 If `nonewline` is set, we will cut off the trailing newline of this given data
 618 before comparing with the one actually received by the client
 619
 620 ### `<stdout [mode="text"] [nonewline="yes"] [crlf="yes"] [loadfile="filename"]>`
 621 This verifies that this data was passed to stdout.
 622
 623 Use the mode="text" attribute if the output is in text mode on platforms that
 624 have a text/binary difference.
 625
 626 If `nonewline` is set, we will cut off the trailing newline of this given data
 627 before comparing with the one actually received by the client
 628
 629 `crlf=yes` forces the newlines to become CRLF even if not written so in the
 630 test.
 631
 632 `loadfile="filename"` makes loading the data from an external file.
 633
 634 ### `<file name="%LOGDIR/filename" [mode="text"]>`
 635 The file's contents must be identical to this after the test is complete. Use
 636 the mode="text" attribute if the output is in text mode on platforms that have
 637 a text/binary difference.
 638
 639 ### `<file1>`
 640 1 to 4 can be appended to 'file' to compare more files.
 641
 642 ### `<file2>`
 643
 644 ### `<file3>`
 645
 646 ### `<file4>`
 647
 648 ### `<stripfile>`
 649 One perl op per line that operates on the output file or stdout before being
 650 compared with what is stored in the test file. This is pretty
 651 advanced. Example: "s/^EPRT .*/EPRT stripped/"
 652
 653 ### `<stripfile1>`
 654 1 to 4 can be appended to `stripfile` to strip the corresponding `<fileN>`
 655 content
 656
 657 ### `<stripfile2>`
 658
 659 ### `<stripfile3>`
 660
 661 ### `<stripfile4>`
 662
 663 ### `<upload>`
 664 the contents of the upload data curl should have sent
 665
 666 ### `<valgrind>`
 667 disable - disables the valgrind log check for this test