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 
    173 For TFTP:
    174 writedelay: [secs] delay this amount between reply packets (each packet being
    175                    512 bytes payload)
    176 </servercmd>
    177 </reply>
    178 
    179 <client>
    180 
    181 <server>
    182 What server(s) this test case requires/uses:
    183 
    184 file
    185 ftp
    186 ftp-ipv6
    187 ftps
    188 http
    189 http-ipv6
    190 http-pipe
    191 http-proxy
    192 http-unix
    193 https
    194 httptls+srp
    195 httptls+srp-ipv6
    196 http/2
    197 imap
    198 none
    199 pop3
    200 rtsp
    201 rtsp-ipv6
    202 scp
    203 sftp
    204 smtp
    205 socks4
    206 socks5
    207 
    208 Give only one per line.  This subsection is mandatory.
    209 </server>
    210 
    211 <features>
    212 A list of features that MUST be present in the client/library for this test to
    213 be able to run. If a required feature is not present then the test will be
    214 SKIPPED.
    215 
    216 Alternatively a feature can be prefixed with an exclamation mark to indicate a
    217 feature is NOT required. If the feature is present then the test will be
    218 SKIPPED.
    219 
    220 Features testable here are:
    221 
    222 axTLS
    223 crypto
    224 debug
    225 getrlimit
    226 GnuTLS
    227 GSS-API
    228 http2
    229 idn
    230 ipv6
    231 Kerberos
    232 large_file
    233 libz
    234 Metalink
    235 NSS
    236 NTLM
    237 OpenSSL
    238 PSL
    239 socks
    240 SPNEGO
    241 SSL
    242 SSLpinning
    243 SSPI
    244 TLS-SRP
    245 TrackMemory
    246 threaded-resolver
    247 unittest
    248 unix-sockets
    249 WinSSL
    250 ld_preload
    251 
    252 as well as each protocol that curl supports.  A protocol only needs to be
    253 specified if it is different from the server (useful when the server
    254 is 'none').
    255 </features>
    256 
    257 <killserver>
    258 Using the same syntax as in <server> but when mentioned here these servers
    259 are explicitly KILLED when this test case is completed. Only use this if there
    260 is no other alternatives. Using this of course requires subsequent tests to
    261 restart servers.
    262 </killserver>
    263 
    264 <precheck>
    265 A command line that if set gets run by the test script before the test. If an
    266 output is displayed by the command or if the return code is non-zero, the test
    267 will be skipped and the (single-line) output will be displayed as reason for
    268 not running the test.  Variables are substituted as in the <command> section.
    269 </precheck>
    270 
    271 <postcheck>
    272 A command line that if set gets run by the test script after the test. If
    273 the command exists with a non-zero status code, the test will be considered
    274 to have failed. Variables are substituted as in the <command> section.
    275 </postcheck>
    276 
    277 <tool>
    278 Name of tool to use instead of "curl". This tool must be built and exist
    279 either in the libtest/ directory (if the tool starts with 'lib') or in the
    280 unit/ directory (if the tool starts with 'unit').
    281 </tool>
    282 
    283 <name>
    284 test case description
    285 </name>
    286 
    287 <setenv>
    288 variable1=contents1
    289 variable2=contents2
    290 
    291 Set the given environment variables to the specified value before the actual
    292 command is run. They are cleared again after the command has been run.
    293 Variables are first substituted as in the <command> section.
    294 </setenv>
    295 
    296 <command [option="no-output/no-include"] [timeout="secs"] [delay="secs"]
    297          [type="perl"]>
    298 command line to run, there's a bunch of %variables that get replaced
    299 accordingly.
    300 
    301 Note that the URL that gets passed to the server actually controls what data
    302 that is returned. The last slash in the URL must be followed by a number. That
    303 number (N) will be used by the test-server to load test case N and return the
    304 data that is defined within the <reply><data></data></reply> section.
    305 
    306 If there's no test number found above, the HTTP test server will use the
    307 number following the last dot in the given hostname (made so that a CONNECT
    308 can still pass on test number) so that "foo.bar.123" gets treated as test case
    309 123. Alternatively, if an IPv6 address is provided to CONNECT, the last
    310 hexadecimal group in the address will be used as the test number! For example
    311 the address "[1234::ff]" would be treated as test case 255.
    312 
    313 Set type="perl" to write the test case as a perl script. It implies that
    314 there's no memory debugging and valgrind gets shut off for this test.
    315 
    316 Set option="no-output" to prevent the test script to slap on the --output
    317 argument that directs the output to a file. The --output is also not added if
    318 the verify/stdout section is used.
    319 
    320 Set option="no-include" to prevent the test script to slap on the --include
    321 argument.
    322 
    323 Set timeout="secs" to override default server logs advisor read lock timeout.
    324 This timeout is used by the test harness, once that the command has completed
    325 execution, to wait for the test server to write out server side log files and
    326 remove the lock that advised not to read them. The "secs" parameter is the not
    327 negative integer number of seconds for the timeout. This 'timeout' attribute
    328 is documented for completeness sake, but is deep test harness stuff and only
    329 needed for very singular and specific test cases. Avoid using it.
    330 
    331 Set delay="secs" to introduce a time delay once that the command has completed
    332 execution and before the <postcheck> section runs. The "secs" parameter is the
    333 not negative integer number of seconds for the delay. This 'delay' attribute
    334 is intended for very specific test cases, and normally not needed.
    335 
    336 Available substitute variables include:
    337 %CLIENT6IP - IPv6 address of the client running curl
    338 %CLIENTIP  - IPv4 address of the client running curl
    339 %CURL      - Path to the curl executable
    340 %FTP2PORT  - Port number of the FTP server 2
    341 %FTP6PORT  - IPv6 port number of the FTP server
    342 %FTPPORT   - Port number of the FTP server
    343 %FTPSPORT  - Port number of the FTPS server
    344 %FTPTIME2  - Timeout in seconds that should be just sufficient to receive
    345              a response from the test FTP server
    346 %FTPTIME3  - Even longer than %FTPTIME2
    347 %GOPHER6PORT  - IPv6 port number of the Gopher server
    348 %GOPHERPORT   - Port number of the Gopher server
    349 %HOST6IP      - IPv6 address of the host running this test
    350 %HOSTIP       - IPv4 address of the host running this test
    351 %HTTP6PORT    - IPv6 port number of the HTTP server
    352 %HTTPPIPEPORT - Port number of the HTTP pipelining server
    353 %HTTPUNIXPATH - Path to the Unix socket of the HTTP server
    354 %HTTPPORT     - Port number of the HTTP server
    355 %HTTPSPORT    - Port number of the HTTPS server
    356 %HTTPTLS6PORT - IPv6 port number of the HTTP TLS server
    357 %HTTPTLSPORT  - Port number of the HTTP TLS server
    358 %IMAP6PORT - IPv6 port number of the IMAP server
    359 %IMAPPORT  - Port number of the IMAP server
    360 %POP36PORT - IPv6 port number of the POP3 server
    361 %POP3PORT  - Port number of the POP3 server
    362 %PROXYPORT - Port number of the HTTP proxy
    363 %PWD       - Current directory
    364 %RTSP6PORT - IPv6 port number of the RTSP server
    365 %RTSPPORT  - Port number of the RTSP server
    366 %SMTP6PORT - IPv6 port number of the SMTP server
    367 %SMTPPORT  - Port number of the SMTP server
    368 %SOCKSPORT - Port number of the SOCKS4/5 server
    369 %SRCDIR    - Full path to the source dir
    370 %SSHPORT   - Port number of the SCP/SFTP server
    371 %TFTP6PORT - IPv6 port number of the TFTP server
    372 %TFTPPORT  - Port number of the TFTP server
    373 %USER      - Login ID of the user running the test
    374 </command>
    375 
    376 <file name="log/filename">
    377 This creates the named file with this content before the test case is run,
    378 which is useful if the test case needs a file to act on.
    379 Variables are substituted on the contents of the file as in the <command>
    380 section.
    381 </file>
    382 
    383 <stdin [nonewline="yes"]>
    384 Pass this given data on stdin to the tool.
    385 
    386 If 'nonewline' is set, we will cut off the trailing newline of this given data
    387 before comparing with the one actually received by the client
    388 </stdin>
    389 
    390 </client>
    391 
    392 <verify>
    393 <errorcode>
    394 numerical error code curl is supposed to return. Specify a list of accepted
    395 error codes by separating multiple numbers with comma. See test 237 for an
    396 example.
    397 </errorcode>
    398 <strip>
    399 One regex per line that is removed from the protocol dumps before the
    400 comparison is made. This is very useful to remove dependencies on dynamically
    401 changing protocol data such as port numbers or user-agent strings.
    402 </strip>
    403 <strippart>
    404 One perl op per line that operates on the protocol dump. This is pretty
    405 advanced. Example: "s/^EPRT .*/EPRT stripped/"
    406 </strippart>
    407 
    408 <protocol [nonewline="yes"]>
    409 
    410 the protocol dump curl should transmit, if 'nonewline' is set, we will cut off
    411 the trailing newline of this given data before comparing with the one actually
    412 sent by the client Variables are substituted as in the <command> section.  The
    413 <strip> and <strippart> rules are applied before comparisons are made.
    414 
    415 </protocol>
    416 
    417 <proxy [nonewline="yes"]>
    418 
    419 The protocol dump curl should transmit to a HTTP proxy (when the http-proxy
    420 server is used), if 'nonewline' is set, we will cut off the trailing newline
    421 of this given data before comparing with the one actually sent by the client
    422 Variables are substituted as in the <command> section. The <strip> and
    423 <strippart> rules are applied before comparisons are made.
    424 
    425 </proxy>
    426 
    427 <stdout [mode="text"] [nonewline="yes"]>
    428 This verifies that this data was passed to stdout.  Variables are
    429 substituted as in the <command> section.
    430 
    431 Use the mode="text" attribute if the output is in text mode on platforms that
    432 have a text/binary difference.
    433 
    434 If 'nonewline' is set, we will cut off the trailing newline of this given data
    435 before comparing with the one actually received by the client
    436 </stdout>
    437 <file name="log/filename" [mode="text"]>
    438 The file's contents must be identical to this after the test is complete.
    439 Use the mode="text" attribute if the output is in text mode on platforms that
    440 have a text/binary difference.
    441 Variables are substituted as in the <command> section.
    442 </file>
    443 <stripfile>
    444 One perl op per line that operates on the output file or stdout before being
    445 compared with what is stored in the test file. This is pretty
    446 advanced. Example: "s/^EPRT .*/EPRT stripped/"
    447 </stripfile>
    448 <upload>
    449 the contents of the upload data curl should have sent
    450 </upload>
    451 <valgrind>
    452 disable - disables the valgrind log check for this test
    453 </valgrind>
    454 </verify>
    455 
    456 </testcase>
    457