moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2024-11-16 06:25:03 -05:00
Code Issues Releases Wiki Activity
537b571c90
curl/tests/data/test579

89 lines
1.7 KiB
Plaintext
Raw Normal View History

test: added test 579 to verify progress callback for chunked post The 66 bytes checked are those 38 bytes with the chunked encoding headers added: 8+8+10+35+5 = 66 The three-letter words become 8 bytes on the wire because they are sent like: "3\r\none\r\n" ... and there's the trailing 5 bytes write after the four lines since the final chunk is sent (which is "0\r\n\r\n").
2010-08-18 18:27:04 -04:00
<testcase>
<info>
<keywords>
HTTP
HTTP POST
HTTP Digest auth
</keywords>
</info>
#
# Server-side
<reply>
<data>
testsuite: changed HTTP and RTSP header line-endings to CRLF According to RFC 2616 and RFC 2326 individual protocol elements, like headers and except the actual content, are terminated by using CRLF. Therefore the test data files for these protocols need to contain mixed line-endings if the actual protocol elements use CRLF while the file uses LF.
2014-01-31 18:52:08 -05:00
HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.0
Date: Sun, 03 Apr 2005 14:57:45 GMT
X-Powered-By: ASP.NET
HTTP/1.1 401 authentication please swsbounce
Server: Microsoft-IIS/6.0
WWW-Authenticate: Digest realm="testrealm", nonce="1053604144"
Content-Type: text/html; charset=iso-8859-1
Content-Length: 0
test: added test 579 to verify progress callback for chunked post The 66 bytes checked are those 38 bytes with the chunked encoding headers added: 8+8+10+35+5 = 66 The three-letter words become 8 bytes on the wire because they are sent like: "3\r\none\r\n" ... and there's the trailing 5 bytes write after the four lines since the final chunk is sent (which is "0\r\n\r\n").
2010-08-18 18:27:04 -04:00
</data>
<data1>
testsuite: changed HTTP and RTSP header line-endings to CRLF According to RFC 2616 and RFC 2326 individual protocol elements, like headers and except the actual content, are terminated by using CRLF. Therefore the test data files for these protocols need to contain mixed line-endings if the actual protocol elements use CRLF while the file uses LF.
2014-01-31 18:52:08 -05:00
HTTP/1.1 200 A OK
Server: Microsoft-IIS/6.0
Content-Type: text/html; charset=iso-8859-1
Content-Length: 3
test: added test 579 to verify progress callback for chunked post The 66 bytes checked are those 38 bytes with the chunked encoding headers added: 8+8+10+35+5 = 66 The three-letter words become 8 bytes on the wire because they are sent like: "3\r\none\r\n" ... and there's the trailing 5 bytes write after the four lines since the final chunk is sent (which is "0\r\n\r\n").
2010-08-18 18:27:04 -04:00
ok
</data1>
<datacheck>
testsuite: changed HTTP and RTSP header line-endings to CRLF According to RFC 2616 and RFC 2326 individual protocol elements, like headers and except the actual content, are terminated by using CRLF. Therefore the test data files for these protocols need to contain mixed line-endings if the actual protocol elements use CRLF while the file uses LF.
2014-01-31 18:52:08 -05:00
HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.0
Date: Sun, 03 Apr 2005 14:57:45 GMT
X-Powered-By: ASP.NET
HTTP/1.1 401 authentication please swsbounce
Server: Microsoft-IIS/6.0
WWW-Authenticate: Digest realm="testrealm", nonce="1053604144"
Content-Type: text/html; charset=iso-8859-1
Content-Length: 0
HTTP/1.1 200 A OK
Server: Microsoft-IIS/6.0
Content-Type: text/html; charset=iso-8859-1
Content-Length: 3
test: added test 579 to verify progress callback for chunked post The 66 bytes checked are those 38 bytes with the chunked encoding headers added: 8+8+10+35+5 = 66 The three-letter words become 8 bytes on the wire because they are sent like: "3\r\none\r\n" ... and there's the trailing 5 bytes write after the four lines since the final chunk is sent (which is "0\r\n\r\n").
2010-08-18 18:27:04 -04:00
ok
</datacheck>
</reply>
# Client-side
<client>
<server>
http
</server>
tests: Made the crypto test feature usable This feature specifies the availability of cryptographic authentication, which can be disabled at compile-time
2014-02-17 03:14:44 -05:00
<features>
crypto
</features>
test: added test 579 to verify progress callback for chunked post The 66 bytes checked are those 38 bytes with the chunked encoding headers added: 8+8+10+35+5 = 66 The three-letter words become 8 bytes on the wire because they are sent like: "3\r\none\r\n" ... and there's the trailing 5 bytes write after the four lines since the final chunk is sent (which is "0\r\n\r\n").
2010-08-18 18:27:04 -04:00
# tool is what to use instead of 'curl'
<tool>
lib579
</tool>
<name>
small chunked HTTP POSTs with digest auth. and progress callback
</name>
<command>
http://%HOSTIP:%HTTPPORT/579 log/ip579
</command>
</client>
#
# Verify data after the test has been "shot"
<verify>
testsuite: use binary output mode for custom curl test tools Do not try to convert line-endings to CRLF on Windows by setting stdout to binary mode, just like the curl tool does if --ascii is not specified. This should prevent corrupted stdout line-ending output like CRCRLF. In order to make the previously naive text-aware tests work with binary mode on Windows, text-mode is disabled for them if it is not actually part of the test case and line-endings are corrected.
2014-01-31 18:58:58 -05:00
<file name="log/ip579">
test: added test 579 to verify progress callback for chunked post The 66 bytes checked are those 38 bytes with the chunked encoding headers added: 8+8+10+35+5 = 66 The three-letter words become 8 bytes on the wire because they are sent like: "3\r\none\r\n" ... and there's the trailing 5 bytes write after the four lines since the final chunk is sent (which is "0\r\n\r\n").
2010-08-18 18:27:04 -04:00
Progress callback called with UL 0 out of 0
Progress callback called with UL 0 out of -1
Progress callback called with UL 8 out of -1
Progress callback called with UL 16 out of -1
Progress callback called with UL 26 out of -1
Progress callback called with UL 61 out of -1
Progress callback called with UL 66 out of -1
</file>
</verify>
</testcase>
Reference in New Issue Copy Permalink