moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2024-11-05 09:05:04 -05:00
Code Issues Releases Wiki Activity
876e66412a
curl/tests/data/test599

87 lines
1.4 KiB
Plaintext
Raw Normal View History

HTTP: reset expected DL/UL sizes on redirects With FOLLOWLOCATION enabled. When a 3xx page is downloaded and the download size was known (like with a Content-Length header), but the subsequent URL (transfered after the 3xx page) was chunked encoded, then the previous "known download size" would linger and cause the progress meter to get incorrect information, ie the former value would remain being sent in. This could easily result in downloads that were WAY larger than "expected" and would cause >100% outputs with the curl command line tool. Test case 599 was created and it was used to repeat the bug and then verify the fix. Bug: http://curl.haxx.se/bug/view.cgi?id=3510057 Reported by: Michael Wallner
2012-03-23 18:42:37 -04:00
<testcase>
<info>
<keywords>
HTTP
HTTP POST
tests: added missing keywords "chunked Transfer-Encoding"
2017-05-13 16:35:15 -04:00
chunked Transfer-Encoding
HTTP: reset expected DL/UL sizes on redirects With FOLLOWLOCATION enabled. When a 3xx page is downloaded and the download size was known (like with a Content-Length header), but the subsequent URL (transfered after the 3xx page) was chunked encoded, then the previous "known download size" would linger and cause the progress meter to get incorrect information, ie the former value would remain being sent in. This could easily result in downloads that were WAY larger than "expected" and would cause >100% outputs with the curl command line tool. Test case 599 was created and it was used to repeat the bug and then verify the fix. Bug: http://curl.haxx.se/bug/view.cgi?id=3510057 Reported by: Michael Wallner
2012-03-23 18:42:37 -04:00
</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 302 OK
Date: Thu, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Location: 5990001
Content-Length: 6
Connection: close
Content-Type: text/html
HTTP: reset expected DL/UL sizes on redirects With FOLLOWLOCATION enabled. When a 3xx page is downloaded and the download size was known (like with a Content-Length header), but the subsequent URL (transfered after the 3xx page) was chunked encoded, then the previous "known download size" would linger and cause the progress meter to get incorrect information, ie the former value would remain being sent in. This could easily result in downloads that were WAY larger than "expected" and would cause >100% outputs with the curl command line tool. Test case 599 was created and it was used to repeat the bug and then verify the fix. Bug: http://curl.haxx.se/bug/view.cgi?id=3510057 Reported by: Michael Wallner
2012-03-23 18:42:37 -04:00
-foo-
</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 OK
Date: Thu, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Transfer-Encoding: chunked
Connection: close
Content-Type: text/html
HTTP: reset expected DL/UL sizes on redirects With FOLLOWLOCATION enabled. When a 3xx page is downloaded and the download size was known (like with a Content-Length header), but the subsequent URL (transfered after the 3xx page) was chunked encoded, then the previous "known download size" would linger and cause the progress meter to get incorrect information, ie the former value would remain being sent in. This could easily result in downloads that were WAY larger than "expected" and would cause >100% outputs with the curl command line tool. Test case 599 was created and it was used to repeat the bug and then verify the fix. Bug: http://curl.haxx.se/bug/view.cgi?id=3510057 Reported by: Michael Wallner
2012-03-23 18:42:37 -04:00
32
this data is slightly larger than the first piece
0
</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 302 OK
Date: Thu, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Location: 5990001
Content-Length: 6
Connection: close
Content-Type: text/html
HTTP/1.1 200 OK
Date: Thu, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Transfer-Encoding: chunked
Connection: close
Content-Type: text/html
HTTP: reset expected DL/UL sizes on redirects With FOLLOWLOCATION enabled. When a 3xx page is downloaded and the download size was known (like with a Content-Length header), but the subsequent URL (transfered after the 3xx page) was chunked encoded, then the previous "known download size" would linger and cause the progress meter to get incorrect information, ie the former value would remain being sent in. This could easily result in downloads that were WAY larger than "expected" and would cause >100% outputs with the curl command line tool. Test case 599 was created and it was used to repeat the bug and then verify the fix. Bug: http://curl.haxx.se/bug/view.cgi?id=3510057 Reported by: Michael Wallner
2012-03-23 18:42:37 -04:00
this data is slightly larger than the first piece
</datacheck>
</reply>
# Client-side
<client>
<server>
http
</server>
# tool is what to use instead of 'curl'
<tool>
lib599
</tool>
# Bug 3510057 pointed out that when following a location to a larger chunked
# encoded page, the first size would still be used in the progress callback
<name>
HTTP GET with progress callback and redirects changing content sizes
</name>
<command>
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
http://%HOSTIP:%HTTPPORT/599 log/ip599
HTTP: reset expected DL/UL sizes on redirects With FOLLOWLOCATION enabled. When a 3xx page is downloaded and the download size was known (like with a Content-Length header), but the subsequent URL (transfered after the 3xx page) was chunked encoded, then the previous "known download size" would linger and cause the progress meter to get incorrect information, ie the former value would remain being sent in. This could easily result in downloads that were WAY larger than "expected" and would cause >100% outputs with the curl command line tool. Test case 599 was created and it was used to repeat the bug and then verify the fix. Bug: http://curl.haxx.se/bug/view.cgi?id=3510057 Reported by: Michael Wallner
2012-03-23 18:42:37 -04:00
</command>
</client>
#
# Verify data after the test has been "shot"
<verify>
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
<file name="log/ip599">
CL: -1
</file>
HTTP: reset expected DL/UL sizes on redirects With FOLLOWLOCATION enabled. When a 3xx page is downloaded and the download size was known (like with a Content-Length header), but the subsequent URL (transfered after the 3xx page) was chunked encoded, then the previous "known download size" would linger and cause the progress meter to get incorrect information, ie the former value would remain being sent in. This could easily result in downloads that were WAY larger than "expected" and would cause >100% outputs with the curl command line tool. Test case 599 was created and it was used to repeat the bug and then verify the fix. Bug: http://curl.haxx.se/bug/view.cgi?id=3510057 Reported by: Michael Wallner
2012-03-23 18:42:37 -04:00
</verify>
</testcase>
Reference in New Issue Copy Permalink