diff options
author | Brad King <brad.king@kitware.com> | 2009-06-11 13:35:11 (GMT) |
---|---|---|
committer | Brad King <brad.king@kitware.com> | 2009-06-11 13:35:11 (GMT) |
commit | 8c5c192b9dff5ad8e7b422ed16935c2c5d2016db (patch) | |
tree | 09b2fb001034d2cea20fc2cb89699e26f9f9cf9e /Utilities/cmcurl-7.19.0/tests/FILEFORMAT | |
parent | 8ddfd1ed7f3cb6647fa679e240675d7065933e7c (diff) | |
download | CMake-8c5c192b9dff5ad8e7b422ed16935c2c5d2016db.zip CMake-8c5c192b9dff5ad8e7b422ed16935c2c5d2016db.tar.gz CMake-8c5c192b9dff5ad8e7b422ed16935c2c5d2016db.tar.bz2 |
ENH: Remove Utilities/cmcurl-7.19.0 source tree
We never build this source tree anymore, so remove it.
Diffstat (limited to 'Utilities/cmcurl-7.19.0/tests/FILEFORMAT')
-rw-r--r-- | Utilities/cmcurl-7.19.0/tests/FILEFORMAT | 324 |
1 files changed, 0 insertions, 324 deletions
diff --git a/Utilities/cmcurl-7.19.0/tests/FILEFORMAT b/Utilities/cmcurl-7.19.0/tests/FILEFORMAT deleted file mode 100644 index e4be47a..0000000 --- a/Utilities/cmcurl-7.19.0/tests/FILEFORMAT +++ /dev/null @@ -1,324 +0,0 @@ - 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> |