diff options
Diffstat (limited to 'Utilities/cmcurl-7.19.0/tests/FILEFORMAT')
-rw-r--r-- | Utilities/cmcurl-7.19.0/tests/FILEFORMAT | 324 |
1 files changed, 324 insertions, 0 deletions
diff --git a/Utilities/cmcurl-7.19.0/tests/FILEFORMAT b/Utilities/cmcurl-7.19.0/tests/FILEFORMAT new file mode 100644 index 0000000..e4be47a --- /dev/null +++ b/Utilities/cmcurl-7.19.0/tests/FILEFORMAT @@ -0,0 +1,324 @@ + The test suite's file format is very simple and extensible, closely +resembling XML. All data for a single test case resides in a single +ASCII file. Labels mark the beginning and the end of all sections, and each +label must be written in its own line. Comments are either XML-style +(enclosed with <!-- and -->) or C-style (beginning with #) and must appear +on their own lines and not alongside actual test data. Most test data files +are syntactically valid XML, although a few files are not (lack of +support for character entities and the preservation of CR/LF characters at +the end of lines are the biggest differences). + + The file begins with a 'testcase' tag, which encompasses the remainder of +the file. + +<testcase> + + Each file is split up in three main sections: reply, client and verify. The +reply section is used for the server to know what to send as a reply for the +requests curl sends, the client section defines how the client should behave +while the verify section defines how to verify that the data stored after a +command has been run ended up correctly. + + Each main section has a number of available subsections that can be +specified, that will be checked/used if specified. This document includes all +the subsections currently supported. + +Main sections are 'info', 'reply', 'client' and 'verify'. + +<info> +<keywords> +A newline-separated list of keywords describing what this test case uses and +tests. Try to use an already used keyword. These keywords will be used for +statistical/informational purposes and for choosing or skipping classes +of tests. "Keywords" must begin with an alphabetic character, "-", "[" +or "{" and may actually consist of multiple words separated by spaces +which are treated together as a single identifier. +</keywords> +</info> + +<reply> +<data [nocheck="1"] [sendzero="yes"] [base64="yes"]> +data to be sent to the client on its request and later verified that it arrived +safely. Set nocheck="1" to prevent the test script from verifying the arrival +of this data. + +If the data contains 'swsclose' anywhere within the start and end tag, and +this is a HTTP test, then the connection will be closed by the server after +this response is sent. If not, the connection will be kept persistent. + +If the data contains 'swsbounce' anywhere within the start and end tag, the +HTTP server will detect if this is a second request using the same test and +part number and will then increase the part number with one. This is useful +for auth tests and similar. + +'sendzero' set to yes means that the (FTP) server will "send" the data even if +the size is zero bytes. Used to verify curl's behaviour on zero bytes +transfers. + +'base64' set to yes means that the data provided in the test-file is a chunk +of data encoded with base64. It is the only way a test case can contain binary +data. (This attribute can in fact be used on any section, but it doesn't make +much sense for other sections than "data"). +</data> +<dataNUM> +Send back this contents instead of the <data> one. The num is set by: +A) The test number in the request line is >10000 and this is the remainder +of [test case number]%10000. +B) The request was HTTP and included digest details, which adds 1000 to NUM +C) If a HTTP request is NTLM type-1, it adds 1001 to num +D) If a HTTP request is NTLM type-3, it adds 1002 to num +</dataNUM> +<datacheck [nonewline="yes"]> +if the data is sent but this is what should be checked afterwards. If +'nonewline' is set, we will cut off the trailing newline of this given data +before comparing with the one actually received by the client +</datacheck> +<size> +number to return on a ftp SIZE command (set to -1 to make this command fail) +</size> +<mdtm> +what to send back if the client sends a (FTP) MDTM command, set to -1 to +have it return that the file doesn't exist +</mdtm> +<postcmd> +special purpose server-command to control its behavior *after* the +reply is sent +For HTTP/HTTPS, these are supported: + +wait [secs] + - Pause for the given time +</postcmd> +<servercmd> +Special-commands for the server. +For FTP, these are supported: + +REPLY [command] [return value] [response string] + - Changes how the server responds to the [command]. [response string] is + evaluated as a perl string, so it can contain embedded \r\n, for example. +COUNT [command] [num] + - Do the REPLY change for [command] only [num] times and then go back to the + built-in approach +DELAY [command] [secs] + - Delay responding to this command for the given time +RETRWEIRDO + - Enable the "weirdo" RETR case when multiple response lines appear at once + when a file is transfered +RETRNOSIZE + - Make sure the RETR response doesn't contain the size of the file +NOSAVE + - Don't actually save what is received +SLOWDOWN + - Send FTP responses with 0.1 sec delay between each byte +PASVBADIP + - makes PASV send back an illegal IP in its 227 response + +For HTTP/HTTPS: +auth_required if this is set and a POST/PUT is made without auth, the + server will NOT wait for the full request body to get sent +idle do nothing after receiving the request, just "sit idle" +stream continuously send data to the client, never-ending +pipe: [num] tell the server to expect this many HTTP requests before + sending back anything, to allow pipelining tests +skip: [num] instructs the server to ignore reading this many bytes from a PUT + or POST request +</servercmd> +</reply> + +<client> + +<server> +What server(s) this test case requires/uses: + +file +ftp +ftp-ipv6 +ftps +http +http-ipv6 +https +none +scp +sftp +socks4 +socks5 + +Give only one per line. This subsection is mandatory. +</server> + +<features> +A list of features that MUST be present in the client/library for this test to +be able to run (if these features are not present, the test will be +SKIPPED). Features testable here are: + +crypto +getrlimit +GnuTLS +idn +ipv6 +large_file +libz +netrc_debug +NSS +OpenSSL +SSL + +as well as each protocol that curl supports. A protocol only needs to be +specified if it is different from the server (useful when the server +is 'none'). +</features> + +<killserver> +Using the same syntax as in <server> but when mentioned here these servers +are explicitly KILLED when this test case is completed. Only use this if there +is no other alternatives. Using this of course requires subsequent tests to +restart servers. +</killserver> + +<precheck> +A command line that if set gets run by the test script before the test. If an +output is displayed by the command, the test will be skipped and the +(single-line) output will be displayed as reason for not running the test. +Variables are substituted as in the <command> section. +</precheck> + +<postcheck> +A command line that if set gets run by the test script after the test. If +the command exists with a non-zero status code, the test will be considered +to have failed. Variables are substituted as in the <command> section. +</postcheck> + +<tool> +Name of tool to use instead of "curl". This tool must be built and exist +in the libtest/ directory. +</tool> + +<name> +test case description +</name> + +<setenv> +variable1=contents1 +variable2=contents2 + +Set the given environment variables to the specified value before the actual +command is run. They are cleared again after the command has been run. +Variables are first substituted as in the <command> section. +</setenv> + +<command [option="no-output"] [timeout="secs"] [delay="secs"]> +command line to run, there's a bunch of %variables that get replaced +accordingly. + +Note that the URL that gets passed to the server actually controls what data +that is returned. The last slash in the URL must be followed by a number. That +number (N) will be used by the test-server to load test case N and return the +data that is defined within the <reply><data></data></reply> section. + +If a CONNECT is used to the server (to emulate HTTPS etc over proxy), the port +number given in the CONNECT request will be used to identify which test that +is being run, if the proxy host name is said to start with 'test'. + +Set option="no-output" to prevent the test script to slap on the --output +argument that directs the output to a file. The --output is also not added if +the verify/stdout section is used. + +Set timeout="secs" to override default server logs advisor read lock timeout. +This timeout is used by the test harness, once that the command has completed +execution, to wait for the test server to write out server side log files and +remove the lock that advised not to read them. The "secs" parameter is the not +negative integer number of seconds for the timeout. This 'timeout' attribute +is documented for completeness sake, but is deep test harness stuff and only +needed for very singular and specific test cases. Avoid using it. + +Set delay="secs" to introduce a time delay once that the command has completed +execution and before the <postcheck> section runs. The "secs" parameter is the +not negative integer number of seconds for the delay. This 'delay' attribute +is intended for very specific test cases, and normally not needed. + +Available substitute variables include: +%CLIENTIP - IPv4 address of the client running curl +%CLIENT6IP - IPv6 address of the client running curl +%HOSTIP - IPv4 address of the host running this test +%HOSTPORT - Port number of the HTTP server +%HOST6IP - IPv6 address of the host running this test +%HOST6PORT - IPv6 port number of the HTTP server +%HTTPSPORT - Port number of the HTTPS server +%FTPPORT - Port number of the FTP server +%FTP6PORT - IPv6 port number of the FTP server +%FTPSPORT - Port number of the FTPS server +%FTP2PORT - Port number of the FTP server 2 +%FTPTIME2 - Timeout in seconds that should be just sufficient to receive + a response from the test FTP server +%TFTPPORT - Port number of the TFTP server +%TFTP6PORT - IPv6 port number of the TFTP server +%SSHPORT - Port number of the SCP/SFTP server +%SOCKSPORT - Port number of the SOCKS4/5 server +%SRCDIR - Full path to the source dir +%PWD - Current directory +%CURL - Path to the curl executable +%USER - Login ID of the user running the test +</command> + +<file name="log/filename"> +This creates the named file with this content before the test case is run, +which is useful if the test case needs a file to act on. +Variables are substituted on the contents of the file as in the <command> +section. +</file> + +<stdin> +Pass this given data on stdin to the tool. +</stdin> + +</client> + +<verify> +<errorcode> +numerical error code curl is supposed to return. Specify a list of accepted +error codes by separating multiple numbers with comma. See test 237 for an +example. +</errorcode> +<strip> +One regex per line that is removed from the protocol dumps before the +comparison is made. This is very useful to remove dependencies on dynamically +changing protocol data such as port numbers or user-agent strings. +</strip> +<strippart> +One perl op per line that operates on the protocol dump. This is pretty +advanced. Example: "s/^EPRT .*/EPRT stripped/" +</strippart> +<protocol [nonewline="yes"]> +the protocol dump curl should transmit, if 'nonewline' is set, we will cut +off the trailing newline of this given data before comparing with the one +actually sent by the client +Variables are substituted as in the <command> section. +</protocol> +<stdout [mode="text"] [nonewline="yes"]> +This verifies that this data was passed to stdout. Variables are +substituted as in the <command> section. + +Use the mode="text" attribute if the output is in text mode on platforms that +have a text/binary difference. + +If 'nonewline' is set, we will cut off the trailing newline of this given data +before comparing with the one actually received by the client +</stdout> +<file name="log/filename" [mode="text"]> +The file's contents must be identical to this after the test is complete. +Use the mode="text" attribute if the output is in text mode on platforms that +have a text/binary difference. +Variables are substituted as in the <command> section. +</file> +<stripfile> +One perl op per line that operates on the file before being compared. This is +pretty advanced. Example: "s/^EPRT .*/EPRT stripped/" +</stripfile> +<upload> +the contents of the upload data curl should have sent +</upload> +<valgrind> +disable - disables the valgrind log check for this test +</valgrind> +</verify> + +</testcase> |