mirror of
https://github.com/moparisthebest/curl
synced 2024-11-10 11:35:07 -05:00
148207e2d7
It seems that some systems (e.g. fairly consistently in some recent Solaris autobuilds) would manage to get to the connect phase before the progress callback was called, resulting in a CURLE_COULDNT_CONNECT error. Reworked the test to point at a test server that never returns a full result so the progress callback always gets a chance to be called before the transfer can complete in some other way.
47 lines
639 B
Plaintext
47 lines
639 B
Plaintext
<testcase>
|
|
<info>
|
|
<keywords>
|
|
PROGRESSFUNCTION
|
|
</keywords>
|
|
</info>
|
|
|
|
# Server-side
|
|
<reply>
|
|
<data nocheck="yes">
|
|
HTTP/1.1 204 PARTIAL
|
|
X-Comment: partial response to keep the client waiting
|
|
</data>
|
|
<postcmd>
|
|
wait 10
|
|
</postcmd>
|
|
</reply>
|
|
|
|
# Client-side
|
|
<client>
|
|
<server>
|
|
http
|
|
</server>
|
|
<tool>
|
|
lib1513
|
|
</tool>
|
|
<name>
|
|
return failure immediately from progress callback
|
|
</name>
|
|
|
|
# this server/host won't be used for real
|
|
<command>
|
|
http://%HOSTIP:%HTTPPORT/1513
|
|
</command>
|
|
</client>
|
|
|
|
# Verify data after the test has been "shot"
|
|
<verify>
|
|
<protocol>
|
|
</protocol>
|
|
# 42 == CURLE_ABORTED_BY_CALLBACK
|
|
<errorcode>
|
|
42
|
|
</errorcode>
|
|
</verify>
|
|
</testcase>
|