summaryrefslogtreecommitdiffstats
path: root/Utilities/cmcurl-7.19.0/tests/FILEFORMAT
diff options
context:
space:
mode:
authorBrad King <brad.king@kitware.com>2009-06-11 13:35:11 (GMT)
committerBrad King <brad.king@kitware.com>2009-06-11 13:35:11 (GMT)
commit8c5c192b9dff5ad8e7b422ed16935c2c5d2016db (patch)
tree09b2fb001034d2cea20fc2cb89699e26f9f9cf9e /Utilities/cmcurl-7.19.0/tests/FILEFORMAT
parent8ddfd1ed7f3cb6647fa679e240675d7065933e7c (diff)
downloadCMake-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/FILEFORMAT324
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>