Home | History | Annotate | Download | only in tests
      1  The test suite's file format is very simple and extensible, closely
      2 resembling XML. All data for a single test case resides in a single
      3 ASCII file. Labels mark the beginning and the end of all sections, and each
      4 label must be written in its own line.  Comments are either XML-style
      5 (enclosed with <!-- and -->) or C-style (beginning with #) and must appear
      6 on their own lines and not alongside actual test data.  Most test data files
      7 are syntactically valid XML, although a few files are not (lack of
      8 support for character entities and the preservation of CR/LF characters at
      9 the end of lines are the biggest differences).
     10 
     11  The file begins with a 'testcase' tag, which encompasses the remainder of
     12 the file.
     13 
     14 <testcase>
     15 
     16  Each file is split up in three main sections: reply, client and verify. The
     17 reply section is used for the server to know what to send as a reply for the
     18 requests curl sends, the client section defines how the client should behave
     19 while the verify section defines how to verify that the data stored after a
     20 command has been run ended up correctly.
     21 
     22  Each main section has a number of available subsections that can be
     23 specified, that will be checked/used if specified. This document includes all
     24 the subsections currently supported.
     25 
     26 Main sections are 'info', 'reply', 'client' and 'verify'.
     27 
     28 <info>
     29 <keywords>
     30 A newline-separated list of keywords describing what this test case uses and
     31 tests. Try to use an already used keyword.  These keywords will be used for
     32 statistical/informational purposes and for choosing or skipping classes
     33 of tests.  "Keywords" must begin with an alphabetic character, "-", "["
     34 or "{" and may actually consist of multiple words separated by spaces
     35 which are treated together as a single identifier.
     36 </keywords>
     37 </info>
     38 
     39 <reply>
     40 <data [nocheck="yes"] [sendzero="yes"] [base64="yes"]>
     41 data to be sent to the client on its request and later verified that it arrived
     42 safely. Set nocheck="yes" to prevent the test script from verifying the arrival
     43 of this data.
     44 
     45 If the data contains 'swsclose' anywhere within the start and end tag, and
     46 this is a HTTP test, then the connection will be closed by the server after
     47 this response is sent. If not, the connection will be kept persistent.
     48 
     49 If the data contains 'swsbounce' anywhere within the start and end tag, the
     50 HTTP server will detect if this is a second request using the same test and
     51 part number and will then increase the part number with one. This is useful
     52 for auth tests and similar.
     53 
     54 'sendzero' set to yes means that the (FTP) server will "send" the data even if
     55 the size is zero bytes. Used to verify curl's behaviour on zero bytes
     56 transfers.
     57 
     58 'base64' set to yes means that the data provided in the test-file is a chunk
     59 of data encoded with base64. It is the only way a test case can contain binary
     60 data. (This attribute can in fact be used on any section, but it doesn't make
     61 much sense for other sections than "data").
     62 
     63 For FTP file listings, the <data> section will be used *only* if you make sure
     64 that there has been a CWD done first to a directory named 'test-[num]' where
     65 [num] is the test case number. Otherwise the ftp server can't know from which
     66 test file to load the list content.
     67 
     68 </data>
     69 <dataNUM>
     70 Send back this contents instead of the <data> one. The num is set by:
     71 A) The test number in the request line is >10000 and this is the remainder
     72 of [test case number]%10000.
     73 B) The request was HTTP and included digest details, which adds 1000 to NUM
     74 C) If a HTTP request is NTLM type-1, it adds 1001 to num
     75 D) If a HTTP request is NTLM type-3, it adds 1002 to num
     76 E) If a HTTP request is Basic and num is already >=1000, it adds 1 to num
     77 F) If a HTTP request is Negotiate, num gets incremented by one for each
     78 request with Negotiate authorization header on the same test case.
     79 
     80 Dynamically changing num in this way allows the test harness to be used to
     81 test authentication negotiation where several different requests must be sent
     82 to complete a transfer. The response to each request is found in its own data
     83 section.  Validating the entire negotiation sequence can be done by
     84 specifying a datacheck section.
     85 </dataNUM>
     86 <connect>
     87 The connect section is used instead of the 'data' for all CONNECT
     88 requests. The remainder of the rules for the data section then apply but with
     89 a connect prefix.
     90 </connect>
     91 <datacheck [mode="text"] [nonewline="yes"]>
     92 if the data is sent but this is what should be checked afterwards. If
     93 'nonewline' is set, we will cut off the trailing newline of this given data
     94 before comparing with the one actually received by the client.
     95 
     96 Use the mode="text" attribute if the output is in text mode on platforms that
     97 have a text/binary difference.
     98 </datacheck>
     99 <datacheckNUM [nonewline="yes"] [mode="text"]>
    100 The contents of numbered datacheck sections are appended to the non-numbered
    101 one.
    102 </datacheckNUM>
    103 <size>
    104 number to return on a ftp SIZE command (set to -1 to make this command fail)
    105 </size>
    106 <mdtm>
    107 what to send back if the client sends a (FTP) MDTM command, set to -1 to
    108 have it return that the file doesn't exist
    109 </mdtm>
    110 <postcmd>
    111 special purpose server-command to control its behavior *after* the
    112 reply is sent
    113 For HTTP/HTTPS, these are supported:
    114 
    115 wait [secs]
    116  - Pause for the given time
    117 </postcmd>
    118 <servercmd>
    119 Special-commands for the server.
    120 For FTP/SMTP/POP/IMAP, these are supported:
    121 
    122 REPLY [command] [return value] [response string]
    123  - Changes how the server responds to the [command]. [response string] is
    124    evaluated as a perl string, so it can contain embedded \r\n, for example.
    125    There's a special [command] named "welcome" (without quotes) which is the
    126    string sent immediately on connect as a welcome.
    127 REPLYLF (like above but sends the response terminated with LF-only and not
    128    CRLF)
    129 COUNT [command] [num]
    130  - Do the REPLY change for [command] only [num] times and then go back to the
    131    built-in approach
    132 DELAY [command] [secs]
    133  - Delay responding to this command for the given time
    134 RETRWEIRDO
    135  - Enable the "weirdo" RETR case when multiple response lines appear at once
    136    when a file is transferred
    137 RETRNOSIZE
    138  - Make sure the RETR response doesn't contain the size of the file
    139 NOSAVE
    140  - Don't actually save what is received
    141 SLOWDOWN
    142  - Send FTP responses with 0.01 sec delay between each byte
    143 PASVBADIP
    144  - makes PASV send back an illegal IP in its 227 response
    145 CAPA [capabilities]
    146  - Enables support for and specifies a list of space separated capabilities to
    147    return to the client for the IMAP CAPABILITY, POP3 CAPA and SMTP EHLO
    148    commands
    149 AUTH [mechanisms]
    150  - Enables support for SASL authentication and specifies a list of space
    151    separated mechanisms for IMAP, POP3 and SMTP
    152 
    153 For HTTP/HTTPS:
    154 auth_required   if this is set and a POST/PUT is made without auth, the
    155                 server will NOT wait for the full request body to get sent
    156 idle            do nothing after receiving the request, just "sit idle"
    157 stream          continuously send data to the client, never-ending
    158 writedelay: [secs] delay this amount between reply packets
    159 pipe: [num]     tell the server to expect this many HTTP requests before
    160                 sending back anything, to allow pipelining tests
    161 skip: [num]     instructs the server to ignore reading this many bytes from a PUT
    162                 or POST request
    163 
    164 rtp: part [num] channel [num] size [num]
    165                stream a fake RTP packet for the given part on a chosen channel
    166                with the given payload size
    167 
    168 connection-monitor When used, this will log [DISCONNECT] to the server.input
    169                log when the connection is disconnected.
    170 upgrade        when an HTTP upgrade header is found, the server will upgrade
    171                to http2
    172 swsclose       instruct server to close connection after response
    173 
    174 For TFTP:
    175 writedelay: [secs] delay this amount between reply packets (each packet being
    176                    512 bytes payload)
    177 </servercmd>
    178 </reply>
    179 
    180 <client>
    181 
    182 <server>
    183 What server(s) this test case requires/uses:
    184 
    185 file
    186 ftp
    187 ftp-ipv6
    188 ftps
    189 http
    190 http-ipv6
    191 http-pipe
    192 http-proxy
    193 http-unix
    194 https
    195 httptls+srp
    196 httptls+srp-ipv6
    197 http/2
    198 imap
    199 none
    200 pop3
    201 rtsp
    202 rtsp-ipv6
    203 scp
    204 sftp
    205 smtp
    206 socks4
    207 socks5
    208 
    209 Give only one per line.  This subsection is mandatory.
    210 </server>
    211 
    212 <features>
    213 A list of features that MUST be present in the client/library for this test to
    214 be able to run. If a required feature is not present then the test will be
    215 SKIPPED.
    216 
    217 Alternatively a feature can be prefixed with an exclamation mark to indicate a
    218 feature is NOT required. If the feature is present then the test will be
    219 SKIPPED.
    220 
    221 Features testable here are:
    222 
    223 crypto
    224 debug
    225 getrlimit
    226 GnuTLS
    227 GSS-API
    228 http/2
    229 idn
    230 ipv6
    231 Kerberos
    232 large_file
    233 libz
    234 manual
    235 Metalink
    236 NSS
    237 NTLM
    238 OpenSSL
    239 PSL
    240 socks
    241 SPNEGO
    242 SSL
    243 SSLpinning
    244 SSPI
    245 TLS-SRP
    246 TrackMemory
    247 threaded-resolver
    248 unittest
    249 unix-sockets
    250 WinSSL
    251 ld_preload
    252 alt-svc
    253 
    254 as well as each protocol that curl supports.  A protocol only needs to be
    255 specified if it is different from the server (useful when the server
    256 is 'none').
    257 </features>
    258 
    259 <killserver>
    260 Using the same syntax as in <server> but when mentioned here these servers
    261 are explicitly KILLED when this test case is completed. Only use this if there
    262 is no other alternatives. Using this of course requires subsequent tests to
    263 restart servers.
    264 </killserver>
    265 
    266 <precheck>
    267 A command line that if set gets run by the test script before the test. If an
    268 output is displayed by the command or if the return code is non-zero, the test
    269 will be skipped and the (single-line) output will be displayed as reason for
    270 not running the test.  Variables are substituted as in the <command> section.
    271 </precheck>
    272 
    273 <postcheck>
    274 A command line that if set gets run by the test script after the test. If
    275 the command exists with a non-zero status code, the test will be considered
    276 to have failed. Variables are substituted as in the <command> section.
    277 </postcheck>
    278 
    279 <tool>
    280 Name of tool to use instead of "curl". This tool must be built and exist
    281 either in the libtest/ directory (if the tool starts with 'lib') or in the
    282 unit/ directory (if the tool starts with 'unit').
    283 </tool>
    284 
    285 <name>
    286 test case description
    287 </name>
    288 
    289 <setenv>
    290 variable1=contents1
    291 variable2=contents2
    292 
    293 Set the given environment variables to the specified value before the actual
    294 command is run. They are cleared again after the command has been run.
    295 Variables are first substituted as in the <command> section.
    296 </setenv>
    297 
    298 <command [option="no-output/no-include/force-output"] [timeout="secs"]
    299          [delay="secs"][type="perl"]>
    300 command line to run, there's a bunch of %variables that get replaced
    301 accordingly.
    302 
    303 Note that the URL that gets passed to the server actually controls what data
    304 that is returned. The last slash in the URL must be followed by a number. That
    305 number (N) will be used by the test-server to load test case N and return the
    306 data that is defined within the <reply><data></data></reply> section.
    307 
    308 If there's no test number found above, the HTTP test server will use the
    309 number following the last dot in the given hostname (made so that a CONNECT
    310 can still pass on test number) so that "foo.bar.123" gets treated as test case
    311 123. Alternatively, if an IPv6 address is provided to CONNECT, the last
    312 hexadecimal group in the address will be used as the test number! For example
    313 the address "[1234::ff]" would be treated as test case 255.
    314 
    315 Set type="perl" to write the test case as a perl script. It implies that
    316 there's no memory debugging and valgrind gets shut off for this test.
    317 
    318 Set option="no-output" to prevent the test script to slap on the --output
    319 argument that directs the output to a file. The --output is also not added if
    320 the verify/stdout section is used.
    321 
    322 Set option="force-output" to make use of --output even when the test is
    323 otherwise written to verify stdout.
    324 
    325 Set option="no-include" to prevent the test script to slap on the --include
    326 argument.
    327 
    328 Set timeout="secs" to override default server logs advisor read lock timeout.
    329 This timeout is used by the test harness, once that the command has completed
    330 execution, to wait for the test server to write out server side log files and
    331 remove the lock that advised not to read them. The "secs" parameter is the not
    332 negative integer number of seconds for the timeout. This 'timeout' attribute
    333 is documented for completeness sake, but is deep test harness stuff and only
    334 needed for very singular and specific test cases. Avoid using it.
    335 
    336 Set delay="secs" to introduce a time delay once that the command has completed
    337 execution and before the <postcheck> section runs. The "secs" parameter is the
    338 not negative integer number of seconds for the delay. This 'delay' attribute
    339 is intended for very specific test cases, and normally not needed.
    340 
    341 Available substitute variables include:
    342 %CLIENT6IP - IPv6 address of the client running curl
    343 %CLIENTIP  - IPv4 address of the client running curl
    344 %CURL      - Path to the curl executable
    345 %FTP2PORT  - Port number of the FTP server 2
    346 %FTP6PORT  - IPv6 port number of the FTP server
    347 %FTPPORT   - Port number of the FTP server
    348 %FTPSPORT  - Port number of the FTPS server
    349 %FTPTIME2  - Timeout in seconds that should be just sufficient to receive
    350              a response from the test FTP server
    351 %FTPTIME3  - Even longer than %FTPTIME2
    352 %GOPHER6PORT  - IPv6 port number of the Gopher server
    353 %GOPHERPORT   - Port number of the Gopher server
    354 %HOST6IP      - IPv6 address of the host running this test
    355 %HOSTIP       - IPv4 address of the host running this test
    356 %HTTP6PORT    - IPv6 port number of the HTTP server
    357 %HTTPPIPEPORT - Port number of the HTTP pipelining server
    358 %HTTPUNIXPATH - Path to the Unix socket of the HTTP server
    359 %HTTPPORT     - Port number of the HTTP server
    360 %HTTPSPORT    - Port number of the HTTPS server
    361 %HTTPTLS6PORT - IPv6 port number of the HTTP TLS server
    362 %HTTPTLSPORT  - Port number of the HTTP TLS server
    363 %IMAP6PORT - IPv6 port number of the IMAP server
    364 %IMAPPORT  - Port number of the IMAP server
    365 %POP36PORT - IPv6 port number of the POP3 server
    366 %POP3PORT  - Port number of the POP3 server
    367 %PROXYPORT - Port number of the HTTP proxy
    368 %PWD       - Current directory
    369 %POSIX_PWD - Current directory somewhat mingw friendly
    370 %FILE_PWD  - Current directory, on windows prefixed with a slash
    371 %RTSP6PORT - IPv6 port number of the RTSP server
    372 %RTSPPORT  - Port number of the RTSP server
    373 %SMTP6PORT - IPv6 port number of the SMTP server
    374 %SMTPPORT  - Port number of the SMTP server
    375 %SOCKSPORT - Port number of the SOCKS4/5 server
    376 %SRCDIR    - Full path to the source dir
    377 %SSHPORT   - Port number of the SCP/SFTP server
    378 %TFTP6PORT - IPv6 port number of the TFTP server
    379 %TFTPPORT  - Port number of the TFTP server
    380 %USER      - Login ID of the user running the test
    381 </command>
    382 
    383 <file name="log/filename">
    384 This creates the named file with this content before the test case is run,
    385 which is useful if the test case needs a file to act on.
    386 Variables are substituted on the contents of the file as in the <command>
    387 section.
    388 </file>
    389 
    390 <stdin [nonewline="yes"]>
    391 Pass this given data on stdin to the tool.
    392 
    393 If 'nonewline' is set, we will cut off the trailing newline of this given data
    394 before comparing with the one actually received by the client
    395 </stdin>
    396 
    397 </client>
    398 
    399 <verify>
    400 <errorcode>
    401 numerical error code curl is supposed to return. Specify a list of accepted
    402 error codes by separating multiple numbers with comma. See test 237 for an
    403 example.
    404 </errorcode>
    405 <strip>
    406 One regex per line that is removed from the protocol dumps before the
    407 comparison is made. This is very useful to remove dependencies on dynamically
    408 changing protocol data such as port numbers or user-agent strings.
    409 </strip>
    410 <strippart>
    411 One perl op per line that operates on the protocol dump. This is pretty
    412 advanced. Example: "s/^EPRT .*/EPRT stripped/"
    413 </strippart>
    414 
    415 <protocol [nonewline="yes"]>
    416 
    417 the protocol dump curl should transmit, if 'nonewline' is set, we will cut off
    418 the trailing newline of this given data before comparing with the one actually
    419 sent by the client Variables are substituted as in the <command> section.  The
    420 <strip> and <strippart> rules are applied before comparisons are made.
    421 
    422 </protocol>
    423 
    424 <proxy [nonewline="yes"]>
    425 
    426 The protocol dump curl should transmit to a HTTP proxy (when the http-proxy
    427 server is used), if 'nonewline' is set, we will cut off the trailing newline
    428 of this given data before comparing with the one actually sent by the client
    429 Variables are substituted as in the <command> section. The <strip> and
    430 <strippart> rules are applied before comparisons are made.
    431 
    432 </proxy>
    433 
    434 <stdout [mode="text"] [nonewline="yes"]>
    435 This verifies that this data was passed to stdout.  Variables are
    436 substituted as in the <command> section.
    437 
    438 Use the mode="text" attribute if the output is in text mode on platforms that
    439 have a text/binary difference.
    440 
    441 If 'nonewline' is set, we will cut off the trailing newline of this given data
    442 before comparing with the one actually received by the client
    443 </stdout>
    444 <file name="log/filename" [mode="text"]>
    445 The file's contents must be identical to this after the test is complete.
    446 Use the mode="text" attribute if the output is in text mode on platforms that
    447 have a text/binary difference.
    448 Variables are substituted as in the <command> section.
    449 </file>
    450 <file1>
    451 1 to 4 can be appended to 'file' to compare more files.
    452 </file1>
    453 <file2>
    454 </file2>
    455 <file3>
    456 </file3>
    457 <file4>
    458 </file4>
    459 <stripfile>
    460 One perl op per line that operates on the output file or stdout before being
    461 compared with what is stored in the test file. This is pretty
    462 advanced. Example: "s/^EPRT .*/EPRT stripped/"
    463 </stripfile>
    464 <stripfile1>
    465 1 to 4 can be appended to 'stripfile' to strip the correspending <fileN>
    466 content
    467 </stripfile1>
    468 <stripfile2>
    469 </stripfile2>
    470 <stripfile3>
    471 </stripfile3>
    472 <stripfile4>
    473 </stripfile4>
    474 <upload>
    475 the contents of the upload data curl should have sent
    476 </upload>
    477 <valgrind>
    478 disable - disables the valgrind log check for this test
    479 </valgrind>
    480 </verify>
    481 
    482 </testcase>
    483