curl/tests/data/test579, branch gemini-meta cURL mirror with patches applied Ensure progress.size_dl/progress.size_ul are always >= 0 2014-09-07T21:23:12+00:00 Brandon Casey drafnel@gmail.com 2014-08-29T21:48:03+00:00 6beb0eeea17cd6cc71cb69737ac63861a8f18d4e 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> 
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>
tests: Made the crypto test feature usable 2014-02-17T08:50:46+00:00 Dan Fandrich dan@coneharvesters.com 2014-02-17T08:14:44+00:00 4b4e8a5853dbda897fad0321b2cbebfb36dfe012 This feature specifies the availability of cryptographic authentication, which can be disabled at compile-time 
This feature specifies the availability of cryptographic
authentication, which can be disabled at compile-time
testsuite: use binary output mode for custom curl test tools 2014-02-14T19:12:27+00:00 Marc Hoersken info@marc-hoersken.de 2014-01-31T23:58:58+00:00 75f00de55c6e8adc513f9ee32383b11e23106a40 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. 
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.
testsuite: changed HTTP and RTSP header line-endings to CRLF 2014-02-14T19:12:26+00:00 Marc Hoersken info@marc-hoersken.de 2014-01-31T23:52:08+00:00 69745aaa45634308c1dca29cbb7881001c6efc5d 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. 
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.
test: added test 579 to verify progress callback for chunked post 2010-08-18T22:27:04+00:00 Julien Chaffraix julien.chaffraix@gmail.com 2010-08-18T22:27:04+00:00 70baf46d8ddfc07b488d17cf0f5d8e23cf7de14e 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"). 
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").