mirror/curl
2
0
Fork 0
mirror of https://github.com/curl/curl.git synced 2024-12-27 06:59:43 +08:00
Code Issues Packages Projects Releases Wiki Activity
46f8911d39
curl/tests/data/test579

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

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-19 06:27:04 +08: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-02-01 07:52:08 +08: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-19 06:27:04 +08: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-02-01 07:52:08 +08: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-19 06:27:04 +08: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-02-01 07:52:08 +08: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-19 06:27:04 +08: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 16:14:44 +08: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-19 06:27:04 +08:00
# tool is what to use instead of 'curl'
<tool>
tests: use %TESTNUMBER instead of fixed number This makes the tests easier to copy and relocate to other test numbers without having to update content. Closes #6738
2021-03-13 00:38:26 +08:00
lib%TESTNUMBER
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-19 06:27:04 +08:00
</tool>
<name>
small chunked HTTP POSTs with digest auth. and progress callback
</name>
<command>
tests: use %TESTNUMBER instead of fixed number This makes the tests easier to copy and relocate to other test numbers without having to update content. Closes #6738
2021-03-13 00:38:26 +08:00
http://%HOSTIP:%HTTPPORT/%TESTNUMBER log/ip%TESTNUMBER
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-19 06:27:04 +08:00
</command>
</client>
#
# Verify data after the test has been "shot"
<verify>
tests: use %TESTNUMBER instead of fixed number This makes the tests easier to copy and relocate to other test numbers without having to update content. Closes #6738
2021-03-13 00:38:26 +08:00
<file name="log/ip%TESTNUMBER">
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-19 06:27:04 +08: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-30 05:48:03 +08: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-19 06:27:04 +08:00
</file>
</verify>
</testcase>
Reference in New Issue Copy Permalink