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

88 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
Ensure progress.size_dl/progress.size_ul are always >= 0 Historically the default "unknown" value for progress.size_dl and progress.size_ul has been zero, since these values are initialized implicitly by the calloc that allocates the curl handle that these variables are a part of. Users of curl that install progress callbacks may expect these values to always be >= 0. Currently it is possible for progress.size_dl and progress.size_ul to by set to a value of -1, if Curl_pgrsSetDownloadSize() or Curl_pgrsSetUploadSize() are passed a "size" of -1 (which a few places currently do, and a following patch will add more). So lets update Curl_pgrsSetDownloadSize() and Curl_pgrsSetUploadSize() so they make sure that these variables always contain a value that is >= 0. Updates test579 and test599. Signed-off-by: Brandon Casey <drafnel@gmail.com>
2014-08-29 17:48:03 -04:00
Progress callback called with UL 8 out of 0
Progress callback called with UL 16 out of 0
Progress callback called with UL 26 out of 0
Progress callback called with UL 61 out of 0
Progress callback called with UL 66 out of 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
</file>
</verify>
</testcase>
Reference in New Issue Copy Permalink