moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2024-12-25 17:48:48 -05:00
Code Issues Releases Wiki Activity
9e03faccc3
curl/tests/libtest/Makefile.inc

572 lines
18 KiB
PHP
Raw Normal View History

Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
# files used only in some libcurl test programs
TESTUTIL = testutil.c testutil.h
tests: enable time tracing on tests 500, 573 and 585
2012-01-17 15:33:17 -05:00
# files used only in some libcurl test programs
TSTTRACE = testtrace.c testtrace.h
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
# files used only in some libcurl test programs
Makefile.inc: fix $(top_srcdir) not allowed in _SOURCES variables
2013-01-19 22:17:11 -05:00
WARNLESS = ../../lib/warnless.c ../../lib/warnless.h
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
# these files are used in every single test program below
SUPPORTFILES = first.c test.h
# These are all libcurl test programs
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
noinst_PROGRAMS = chkhostname libauthretry libntlmconnect \
test1148: disable if decimal separator is not point Modifying the locale with environment variables doesn't work for native Windows applications. Just disable the test in this case if the decimal separator is something different than a point. Use a precheck with a small C program to achieve that. Closes https://github.com/curl/curl/pull/2786
2018-07-24 17:26:45 -04:00
chkdecimalpoint \
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
lib500 lib501 lib502 lib503 lib504 lib505 lib506 lib507 lib508 lib509 \
lib510 lib511 lib512 lib513 lib514 lib515 lib516 lib517 lib518 lib519 \
lib520 lib521 lib523 lib524 lib525 lib526 lib527 lib529 lib530 lib532 \
pipelining: removed As previously planned and documented in DEPRECATE.md, all pipelining code is removed. Closes #3651
2019-04-05 10:38:36 -04:00
lib533 lib537 lib539 lib540 lib541 lib542 lib543 lib544 lib545 \
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
lib547 lib548 lib549 lib552 lib553 lib554 lib555 lib556 lib557 lib558 \
test559: verify use of minimum CURLOPT_BUFFERSIZE
2017-05-04 09:39:04 -04:00
lib559 lib560 lib562 lib564 lib565 lib566 lib567 lib568 lib569 lib570 \
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
lib571 lib572 lib573 lib574 lib575 lib576 lib578 lib579 lib582 \
mime: tests and examples. Additional mime-specific tests. Existing tests updated to reflect small differences (Expect: 100-continue, data size change due to empty lines, etc). Option -F headers= keyword added to tests. test1135 disabled until the entry point order change is resolved. New example smtp-mime. Examples postit2 and multi-post converted from form API to mime API.
2017-09-02 14:08:45 -04:00
lib583 lib585 lib586 lib587 lib589 lib590 lib591 lib597 lib598 lib599 \
setopt: add CURLOPT_CURLU Allows an application to pass in a pre-parsed URL via a URL handle. Closes #3227
2018-11-01 14:16:15 -04:00
lib643 lib644 lib645 lib650 lib651 lib652 lib653 lib654 lib655 lib658 \
FTP: add test for FTPFILE_NOCWD: Avoid redundant CWDs Add libtest 661 Closes #4417
2019-09-24 13:58:35 -04:00
lib659 lib661 \
http resume: skip body if http code 416 (range error) is ignored. This avoids appending error data to already existing good data. Test 92 is updated to match this change. New test 1156 checks all combinations of --range/--resume, --fail, Content-Range header and http status code 200/416. Fixes #1163 Reported-By: Ithubg on github Closes #2578
2018-05-22 07:23:02 -04:00
lib1156 \
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
lib1500 lib1501 lib1502 lib1503 lib1504 lib1505 lib1506 lib1507 lib1508 \
tests: added test1517 ... for checking ability to receive full HTTP response when POST request is used with slow read callback function. This test checks for bug #657 and verifies the work-around from 72d5e144fbc6. Closes #720
2016-03-17 13:04:20 -04:00
lib1509 lib1510 lib1511 lib1512 lib1513 lib1514 lib1515 lib1517 \
test1523: basic test of CURLOPT_LOW_SPEED_LIMIT
2019-06-13 06:08:57 -04:00
lib1518 lib1520 lib1521 lib1522 lib1523 \
easy: Initialize info variables on easy init and duphandle - Call Curl_initinfo on init and duphandle. Prior to this change the statistical and informational variables were simply zeroed by calloc on easy init and duphandle. While zero is the correct default value for almost all info variables, there is one where it isn't (filetime initializes to -1). Bug: https://github.com/curl/curl/issues/1103 Reported-by: Neal Poole
2016-11-05 23:05:52 -04:00
lib1525 lib1526 lib1527 lib1528 lib1529 lib1530 lib1531 lib1532 lib1533 \
test1538: verify the libcurl strerror API calls
2017-06-02 07:52:55 -04:00
lib1534 lib1535 lib1536 lib1537 lib1538 \
test1541: threaded connection sharing The threaded-shared-conn.c example turned into test case. Only works if pthread was detected. An attempt to detect future regressions such as e3a53e3efb942a5 Closes #3687
2019-03-17 18:37:35 -04:00
lib1540 lib1541 \
multi: fix crash due to dangling entry in connect-pending list Fixes #2677 Closes #2679
2018-06-22 23:11:26 -04:00
lib1550 lib1551 lib1552 lib1553 lib1554 lib1555 lib1556 lib1557 \
CURL_MAX_INPUT_LENGTH: largest acceptable string input size This limits all accepted input strings passed to libcurl to be less than CURL_MAX_INPUT_LENGTH (8000000) bytes, for these API calls: curl_easy_setopt() and curl_url_set(). The 8000000 number is arbitrary picked and is meant to detect mistakes or abuse, not to limit actual practical use cases. By limiting the acceptable string lengths we also reduce the risk of integer overflows all over. NOTE: This does not apply to `CURLOPT_POSTFIELDS`. Test 1559 verifies. Closes #3805
2019-04-29 02:00:49 -04:00
lib1558 lib1559 lib1560 \
CURLINFO_RETRY_AFTER: parse the Retry-After header value This is only the libcurl part that provides the information. There's no user of the parsed value. This change includes three new tests for the parser. Ref: #3794
2019-08-06 05:30:08 -04:00
lib1591 lib1592 lib1593 lib1594 lib1596 \
test1906: verify CURLOPT_CURLU + CURLOPT_PORT usage Based-on-code-by: Poul T Lomholt
2019-04-11 05:28:11 -04:00
lib1900 lib1905 lib1906 \
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
lib2033
NTLM tests: boost coverage by forcing the hostname A shared library tests/libtest/.libs/lihostname.so is preloaded in NTLM test-cases to override the system implementation of gethostname(). It makes it possible to test the NTLM authentication for exact match, and this way test the implementation of MD4 and DES. If LD_PRELOAD doesn't work, a debug build willl also workk as debug builds are now made to prefer a specific environment variable and will then return that content as host name instead of the actual one. Kamil wrote the bulk of this, Daniel Stenberg polished it.
2010-07-29 18:47:49 -04:00
test1148: disable if decimal separator is not point Modifying the locale with environment variables doesn't work for native Windows applications. Just disable the test in this case if the decimal separator is something different than a point. Use a precheck with a small C program to achieve that. Closes https://github.com/curl/curl/pull/2786
2018-07-24 17:26:45 -04:00
chkdecimalpoint_SOURCES = chkdecimalpoint.c ../../lib/mprintf.c \
../../lib/curl_ctype.c
chkdecimalpoint_LDADD =
chkdecimalpoint_CPPFLAGS = $(AM_CPPFLAGS) -DCURL_STATICLIB \
-DCURLX_NO_MEMORY_CALLBACKS
Makefile.inc: fix $(top_srcdir) not allowed in _SOURCES variables
2013-01-19 22:17:11 -05:00
chkhostname_SOURCES = chkhostname.c ../../lib/curl_gethostname.c
build: libhostname and chkhostname linkage adjustments followup
2010-08-08 23:45:11 -04:00
chkhostname_LDADD = @CURL_NETWORK_LIBS@
build: chkhostname build adjustments followup
2010-08-07 11:39:36 -04:00
chkhostname_DEPENDENCIES =
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
chkhostname_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
libntlmconnect_SOURCES = libntlmconnect.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
libntlmconnect_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
libntlmconnect_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
libauthretry_SOURCES = libauthretry.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
libauthretry_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
tests: enable time tracing on tests 500, 573 and 585
2012-01-17 15:33:17 -05:00
lib500_SOURCES = lib500.c $(SUPPORTFILES) $(TESTUTIL) $(TSTTRACE)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib500_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib500_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib501_SOURCES = lib501.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib501_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
test suite: libtest header inclusion cleanup - follow-up Adjust tests/libtest/Makefile.inc and remove a couple of unused headers from tests/libtest/lib583.c
2011-09-06 12:11:11 -04:00
lib502_SOURCES = lib502.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib502_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib502_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib503_SOURCES = lib503.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib503_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib503_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib504_SOURCES = lib504.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib504_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib504_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib505_SOURCES = lib505.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib505_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib506_SOURCES = lib506.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib506_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib507_SOURCES = lib507.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib507_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib507_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib508_SOURCES = lib508.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib508_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
test509: libcurl initialization with memory callbacks and actual usage
2013-03-13 16:49:50 -04:00
lib509_SOURCES = lib509.c $(SUPPORTFILES)
lib509_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib510_SOURCES = lib510.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib510_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib511_SOURCES = lib511.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib511_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib512_SOURCES = lib512.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib512_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib513_SOURCES = lib513.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib513_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib514_SOURCES = lib514.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib514_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib515_SOURCES = lib515.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib515_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib516_SOURCES = lib516.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib516_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib517_SOURCES = lib517.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib517_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
test suite: libtest header inclusion cleanup - follow-up Adjust tests/libtest/Makefile.inc and remove a couple of unused headers from tests/libtest/lib583.c
2011-09-06 12:11:11 -04:00
lib518_SOURCES = lib518.c $(SUPPORTFILES) $(WARNLESS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib518_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib519_SOURCES = lib519.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib519_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib520_SOURCES = lib520.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib520_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib521_SOURCES = lib521.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib521_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib523_SOURCES = lib523.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib523_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib524_SOURCES = lib524.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib524_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib525_SOURCES = lib525.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib525_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib525_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib526_SOURCES = lib526.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib526_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib526_CPPFLAGS = $(AM_CPPFLAGS) -DLIB526
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib527_SOURCES = lib526.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib527_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib527_CPPFLAGS = $(AM_CPPFLAGS) -DLIB527
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib529_SOURCES = lib525.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib529_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib529_CPPFLAGS = $(AM_CPPFLAGS) -DLIB529
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib530_SOURCES = lib530.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib530_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib530_CPPFLAGS = $(AM_CPPFLAGS) -DLIB530
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib532_SOURCES = lib526.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib532_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib532_CPPFLAGS = $(AM_CPPFLAGS) -DLIB532
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib533_SOURCES = lib533.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib533_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib533_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
test suite: libtest header inclusion cleanup - follow-up Adjust tests/libtest/Makefile.inc and remove a couple of unused headers from tests/libtest/lib583.c
2011-09-06 12:11:11 -04:00
lib537_SOURCES = lib537.c $(SUPPORTFILES) $(WARNLESS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib537_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib539_SOURCES = lib539.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib539_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
multi tests: OOM handling fixes Additionally, improved error checking and logging.
2011-10-21 10:26:18 -04:00
lib540_SOURCES = lib540.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib540_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib540_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib541_SOURCES = lib541.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib541_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib542_SOURCES = lib542.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib542_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib543_SOURCES = lib543.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib543_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib544_SOURCES = lib544.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib544_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib545_SOURCES = lib544.c $(SUPPORTFILES)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib545_CPPFLAGS = $(AM_CPPFLAGS) -DLIB545
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib547_SOURCES = lib547.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib547_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib548_SOURCES = lib547.c $(SUPPORTFILES)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib548_CPPFLAGS = $(AM_CPPFLAGS) -DLIB548
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib549_SOURCES = lib549.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib549_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
fix several compiler warnings
2012-03-21 21:40:19 -04:00
lib552_SOURCES = lib552.c $(SUPPORTFILES) $(WARNLESS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib552_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib553_SOURCES = lib553.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib553_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib554_SOURCES = lib554.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib554_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
lib555_SOURCES = lib555.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib555_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib555_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
test556: Fixed compilation warning lib556.c:90: warning: conversion to 'unsigned int' from 'size_t' may alter its value
2014-12-28 15:32:46 -05:00
lib556_SOURCES = lib556.c $(SUPPORTFILES) $(WARNLESS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib556_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
lib557_SOURCES = lib557.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib557_CPPFLAGS = $(AM_CPPFLAGS)
Added missing tests in CMake, added Makefile.inc for tests (+ use in CMake scripts), and fixed a missing define under windows in a test source file.
2009-04-07 17:59:15 -04:00
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
lib558_SOURCES = lib558.c $(SUPPORTFILES)
lib558_CPPFLAGS = $(AM_CPPFLAGS)
test559: verify use of minimum CURLOPT_BUFFERSIZE
2017-05-04 09:39:04 -04:00
lib559_SOURCES = lib559.c $(SUPPORTFILES)
lib559_CPPFLAGS = $(AM_CPPFLAGS)
multi tests: OOM handling fixes Additionally, improved error checking and logging.
2011-10-21 10:26:18 -04:00
lib560_SOURCES = lib560.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib560_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib560_CPPFLAGS = $(AM_CPPFLAGS)
- I was going to fix issue #59 in KNOWN_BUGS If the CURLOPT_PORT option is used on an FTP URL like "ftp://example.com/file;type=A" the ";type=A" is stripped off. I added test case 562 to verify, only to find out that I couldn't repeat this bug so I hereby consider it not a bug anymore!
2009-04-30 05:02:39 -04:00
lib562_SOURCES = lib562.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib562_CPPFLAGS = $(AM_CPPFLAGS)
Added test 564 as DISABLED. It is for testing FTP over a SOCK4 proxy using the multi interface, which currently doesn't work because of how the data connection is not waiting for connect before it tries to do proxy magic.
2009-05-11 07:43:55 -04:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib564_SOURCES = lib564.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib564_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib564_CPPFLAGS = $(AM_CPPFLAGS)
- "Tom" posted a bug report that mentioned how libcurl did wrong when doing a POST using a read callback, with Digest authentication and "Transfer-Encoding: chunked" enforced. I would then cause the first request to be wrongly sent and then basically hang until the server closed the connection. I fixed the problem and added test case 565 to verify it.
2009-10-30 18:24:48 -04:00
lib565_SOURCES = lib510.c $(SUPPORTFILES)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib565_CPPFLAGS = $(AM_CPPFLAGS) -DLIB565
Added test case 566 in an attempt to repeat bug 2884561 (http://curl.haxx.se/bug/view.cgi?id=2884561) but it seems to work for me...
2009-10-30 18:38:21 -04:00
lib566_SOURCES = lib566.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib566_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
lib567_SOURCES = lib567.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib567_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
lib568_SOURCES = lib568.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib568_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
lib569_SOURCES = lib569.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib569_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
lib570_SOURCES = lib570.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib570_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
fix several compiler warnings
2012-03-21 21:40:19 -04:00
lib571_SOURCES = lib571.c $(SUPPORTFILES) $(WARNLESS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib571_CPPFLAGS = $(AM_CPPFLAGS)
Chris Conroy provided first RTSP tests
2010-01-27 23:58:03 -05:00
Fix RTSP GET_PARAMETER empty and non-empty operation. Test coverage included. Thanks to Massimo Callegari for the bug report
2010-03-24 01:35:03 -04:00
lib572_SOURCES = lib572.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib572_CPPFLAGS = $(AM_CPPFLAGS)
Fix RTSP GET_PARAMETER empty and non-empty operation. Test coverage included. Thanks to Massimo Callegari for the bug report
2010-03-24 01:35:03 -04:00
tests: enable time tracing on tests 500, 573 and 585
2012-01-17 15:33:17 -05:00
lib573_SOURCES = lib573.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS) $(TSTTRACE)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib573_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib573_CPPFLAGS = $(AM_CPPFLAGS)
progress: callback for POSTs less than MAX_INITIAL_POST_SIZE Add a call to Curl_pgrsSetUploadSize in this case valided by a test case. Reported by: Никита Дорохин. Bug: http://curl.haxx.se/mail/lib-2010-04/0173.html
2010-08-16 16:54:19 -04:00
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
lib574_SOURCES = lib574.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib574_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
lib575_SOURCES = lib575.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib575_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib575_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
lib576_SOURCES = lib576.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib576_CPPFLAGS = $(AM_CPPFLAGS)
tests/libtest/Makefile.inc: sort build targets
2013-01-15 10:04:31 -05:00
progress: callback for POSTs less than MAX_INITIAL_POST_SIZE Add a call to Curl_pgrsSetUploadSize in this case valided by a test case. Reported by: Никита Дорохин. Bug: http://curl.haxx.se/mail/lib-2010-04/0173.html
2010-08-16 16:54:19 -04:00
lib578_SOURCES = lib578.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib578_CPPFLAGS = $(AM_CPPFLAGS)
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
lib579_SOURCES = lib579.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib579_CPPFLAGS = $(AM_CPPFLAGS)
unittest: framework for unit-testing This is the first approach at doing fairly clean and easy to write and debug unit tests.
2011-01-01 11:33:42 -05:00
compiler warning: fix Fix compiler warning: variable was set but never used Fix compiler warning: clobber ignored
2011-05-26 06:40:04 -04:00
lib582_SOURCES = lib582.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib582_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib582_CPPFLAGS = $(AM_CPPFLAGS)
sftp-multi: test 582 added Add test 582 for uploading a file using sftp and the multi interface. (Patch and test slightly tweaked by Daniel Stenberg) Initially marked as disabled until it is fixed in the source.
2011-03-07 18:19:49 -05:00
test583: verify early SSH multi remove handle This test case is meant to verify that the logic in commit 60172a0446bbe3f8b actually works. This test failed for me before that change and it works after it.
2011-03-12 18:18:04 -05:00
lib583_SOURCES = lib583.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib583_CPPFLAGS = $(AM_CPPFLAGS)
tests: verify OPEN/CLOSESOCKETFUNCTION Test 585 and 586 were added. Using a modified lib500.c
2011-05-18 15:48:14 -04:00
tests: enable time tracing on tests 500, 573 and 585
2012-01-17 15:33:17 -05:00
lib585_SOURCES = lib500.c $(SUPPORTFILES) $(TESTUTIL) $(TSTTRACE)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib585_LDADD = $(TESTUTIL_LIBS)
makefile: avoid preprocessor definition usage when linking
2011-06-01 08:43:25 -04:00
lib585_CPPFLAGS = $(AM_CPPFLAGS) -DLIB585
formdata: ack read callback abort When doing a multipart formpost with a read callback, and that callback returns CURL_READFUNC_ABORT, that return code must be properly propagated back and handled accordingly. Previously it would be handled as a zero byte read which would cause a hang! Added test case 587 to verify. It uses the lib554.c source code with a small ifdef. Reported by: Anton Bychkov Bug: http://curl.haxx.se/mail/lib-2011-10/0097.html
2011-10-15 19:07:29 -04:00
libtest build: add the missing lib586
2011-11-17 17:33:42 -05:00
lib586_SOURCES = lib586.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib586_CPPFLAGS = $(AM_CPPFLAGS)
libtest build: add the missing lib586
2011-11-17 17:33:42 -05:00
formdata: ack read callback abort When doing a multipart formpost with a read callback, and that callback returns CURL_READFUNC_ABORT, that return code must be properly propagated back and handled accordingly. Previously it would be handled as a zero byte read which would cause a hang! Added test case 587 to verify. It uses the lib554.c source code with a small ifdef. Reported by: Anton Bychkov Bug: http://curl.haxx.se/mail/lib-2011-10/0097.html
2011-10-15 19:07:29 -04:00
lib587_SOURCES = lib554.c $(SUPPORTFILES)
lib587_CPPFLAGS = $(AM_CPPFLAGS) -DLIB587
test 589: active FTP upload using multi timeout and EPRT disabled server
2011-10-26 12:55:35 -04:00
mime: tests and examples. Additional mime-specific tests. Existing tests updated to reflect small differences (Expect: 100-continue, data size change due to empty lines, etc). Option -F headers= keyword added to tests. test1135 disabled until the entry point order change is resolved. New example smtp-mime. Examples postit2 and multi-post converted from form API to mime API.
2017-09-02 14:08:45 -04:00
lib589_SOURCES = lib589.c $(SUPPORTFILES)
lib589_CPPFLAGS = $(AM_CPPFLAGS)
test 590: verify the bug fix in 4851dafcf1 This test is created to verify Rene Bernhardt's patch which makes sure libcurl properly _not_ deals with Negotiate if not asked to even if the proxy says it can serve it.
2011-11-06 11:28:28 -05:00
lib590_SOURCES = lib590.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib590_CPPFLAGS = $(AM_CPPFLAGS)
Active mode FTP test cases with server not establishing data connection 591 -> FTP multi PORT and 425 on upload 592 -> FTP multi PORT and 421 on upload 593 -> FTP multi PORT upload, no data conn and no transient neg. reply 594 -> FTP multi PORT upload, no data conn and no positive prelim. reply 1206 -> FTP PORT and 425 on download 1207 -> FTP PORT and 421 on download 1208 -> FTP PORT download, no data conn and no transient negative reply 1209 -> FTP PORT download, no data conn and no positive preliminary reply
2011-11-11 13:46:44 -05:00
lib591_SOURCES = lib591.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib591_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib591_CPPFLAGS = $(AM_CPPFLAGS)
multi interface: fix block when CONNECT_ONLY option is used
2011-12-06 17:41:24 -05:00
lib597_SOURCES = lib597.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib597_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib597_CPPFLAGS = $(AM_CPPFLAGS)
curl_easy_reset: reset the referer string When CURLOPT_REFERER has been used, curl_easy_reset() did not properly clear it. Verified with the new test 598 Bug: http://curl.haxx.se/bug/view.cgi?id=3481551 Reported by: Michael Day
2012-02-06 16:59:49 -05:00
lib598_SOURCES = lib598.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib598_CPPFLAGS = $(AM_CPPFLAGS)
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
lib599_SOURCES = lib599.c $(SUPPORTFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib599_CPPFLAGS = $(AM_CPPFLAGS)
Add tests of auth retries
2012-07-19 13:58:10 -04:00
mime: tests and examples. Additional mime-specific tests. Existing tests updated to reflect small differences (Expect: 100-continue, data size change due to empty lines, etc). Option -F headers= keyword added to tests. test1135 disabled until the entry point order change is resolved. New example smtp-mime. Examples postit2 and multi-post converted from form API to mime API.
2017-09-02 14:08:45 -04:00
lib643_SOURCES = lib643.c $(SUPPORTFILES)
lib643_CPPFLAGS = $(AM_CPPFLAGS)
lib644_SOURCES = lib643.c $(SUPPORTFILES)
lib644_CPPFLAGS = $(AM_CPPFLAGS) -DLIB644
lib645_SOURCES = lib643.c $(SUPPORTFILES)
lib645_CPPFLAGS = $(AM_CPPFLAGS) -DLIB645
form API: add new test 650. Now that the form API is deprecated and not used anymore in curl tool, a lot of its features left untested. Test 650 attempts to check all these features not tested elsewhere.
2017-09-07 14:11:02 -04:00
lib650_SOURCES = lib650.c $(SUPPORTFILES)
lib650_CPPFLAGS = $(AM_CPPFLAGS)
test651: curl_formadd with huge COPYCONTENTS
2017-10-12 14:00:43 -04:00
lib651_SOURCES = lib651.c $(SUPPORTFILES)
lib651_CPPFLAGS = $(AM_CPPFLAGS)
test652: curl_mime_data + base64 encoder with large contents
2017-10-19 13:37:19 -04:00
lib652_SOURCES = lib652.c $(SUPPORTFILES)
lib652_CPPFLAGS = $(AM_CPPFLAGS)
test653: check reuse of easy handle after mime data change See issue #1999
2017-10-20 09:01:14 -04:00
lib653_SOURCES = lib653.c $(SUPPORTFILES)
lib653_CPPFLAGS = $(AM_CPPFLAGS)
mime: clone mime tree upon easy handle duplication. A mime tree attached to an easy handle using CURLOPT_MIMEPOST is strongly bound to the handle: there is a pointer to the easy handle in each item of the mime tree and following the parent pointer list of mime items ends in a dummy part stored within the handle. Because of this binding, a mime tree cannot be shared between different easy handles, thus it needs to be cloned upon easy handle duplication. There is no way for the caller to get the duplicated mime tree handle: it is then set to be automatically destroyed upon freeing the new easy handle. New test 654 checks proper mime structure duplication/release. Add a warning note in curl_mime_data_cb() documentation about sharing user data between duplicated handles. Closes #2235
2018-01-14 13:43:12 -05:00
lib654_SOURCES = lib654.c $(SUPPORTFILES)
lib654_CPPFLAGS = $(AM_CPPFLAGS)
url: Add option CURLOPT_RESOLVER_START_FUNCTION - Add new option CURLOPT_RESOLVER_START_FUNCTION to set a callback that will be called every time before a new resolve request is started (ie before a host is resolved) with a pointer to backend-specific resolver data. Currently this is only useful for ares. - Add new option CURLOPT_RESOLVER_START_DATA to set a user pointer to pass to the resolver start callback. Closes https://github.com/curl/curl/pull/2311
2018-02-14 12:20:43 -05:00
lib655_SOURCES = lib655.c $(SUPPORTFILES)
lib655_CPPFLAGS = $(AM_CPPFLAGS)
setopt: add CURLOPT_CURLU Allows an application to pass in a pre-parsed URL via a URL handle. Closes #3227
2018-11-01 14:16:15 -04:00
lib658_SOURCES = lib658.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib658_LDADD = $(TESTUTIL_LIBS)
lib658_CPPFLAGS = $(AM_CPPFLAGS)
CURLU: fix NULL dereference when used over proxy Test 659 verifies Also fixed the test 658 name Closes #3641
2019-03-04 06:03:39 -05:00
lib659_SOURCES = lib659.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib659_LDADD = $(TESTUTIL_LIBS)
lib659_CPPFLAGS = $(AM_CPPFLAGS)
FTP: add test for FTPFILE_NOCWD: Avoid redundant CWDs Add libtest 661 Closes #4417
2019-09-24 13:58:35 -04:00
lib661_SOURCES = lib661.c $(SUPPORTFILES)
lib661_CPPFLAGS = $(AM_CPPFLAGS)
Unit test for curl_multi_wait()
2012-09-01 17:27:11 -04:00
lib1500_SOURCES = lib1500.c $(SUPPORTFILES) $(TESTUTIL)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib1500_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib1500_CPPFLAGS = $(AM_CPPFLAGS)
Unit test for curl_multi_wait()
2012-09-01 17:27:11 -04:00
Fix compilation of lib1501
2012-11-08 10:36:55 -05:00
lib1501_SOURCES = lib1501.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
build: prevent global LIBS from influencing libtest build targets
2012-11-30 08:34:48 -05:00
lib1501_LDADD = $(TESTUTIL_LIBS)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
lib1501_CPPFLAGS = $(AM_CPPFLAGS)
FTP: prevent the multi interface from blocking As pointed out in Bug report #3579064, curl_multi_perform() would wrongly use a blocking mechanism internally for some commands which could lead to for example a very long block if the LIST response never showed. The solution was to make sure to properly continue to use the multi interface non-blocking state machine. The new test 1501 verifies the fix. Bug: http://curl.haxx.se/bug/view.cgi?id=3579064 Reported by: Guido Berhoerster
2012-11-04 12:22:48 -05:00
test 1502: OOM handling fixes
2012-12-23 15:22:03 -05:00
lib1502_SOURCES = lib1502.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1502_LDADD = $(TESTUTIL_LIBS)
test 1503: same as 1502 but with a different cleanup sequence
2012-12-23 15:33:26 -05:00
lib1502_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1502
lib1503_SOURCES = lib1502.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1503_LDADD = $(TESTUTIL_LIBS)
lib1503_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1503
fixed memory leak: CURLOPT_RESOLVE with multi interface DNS cache entries populated with CURLOPT_RESOLVE were not properly freed again when done using the multi interface. Test case 1502 added to verify. Bug: http://curl.haxx.se/bug/view.cgi?id=3575448 Reported by: Alex Gruz
2012-11-18 10:17:37 -05:00
test 1504 and 1505: same as 1502 but with different cleanup sequences
2012-12-24 08:04:34 -05:00
lib1504_SOURCES = lib1502.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1504_LDADD = $(TESTUTIL_LIBS)
lib1504_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1504
lib1505_SOURCES = lib1502.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1505_LDADD = $(TESTUTIL_LIBS)
lib1505_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1505
CURLMOPT_MAXCONNECTS: restore functionality When a connection is no longer used, it is kept in the cache. If the cache is full, the oldest idle connection is closed. If no connection is idle, the current one is closed instead.
2013-02-05 03:07:27 -05:00
lib1506_SOURCES = lib1506.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1506_LDADD = $(TESTUTIL_LIBS)
lib1506_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1506
DONE: consider callback-aborted transfers premature This bug report properly identified that when doing SMTP and aborting the transfer with a callback, it must be considered aborted prematurely by the code to avoid QUIT etc to be attempted as that would cause a hang. The new test case 1507 verifies this behavior. Reported by: Patricia Muscalu Bug: http://curl.haxx.se/bug/view.cgi?id=1184
2013-02-08 07:48:56 -05:00
http resume: skip body if http code 416 (range error) is ignored. This avoids appending error data to already existing good data. Test 92 is updated to match this change. New test 1156 checks all combinations of --range/--resume, --fail, Content-Range header and http status code 200/416. Fixes #1163 Reported-By: Ithubg on github Closes #2578
2018-05-22 07:23:02 -04:00
lib1156_SOURCES = lib1156.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1156_LDADD = $(TESTUTIL_LIBS)
lib1156_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1156
DONE: consider callback-aborted transfers premature This bug report properly identified that when doing SMTP and aborting the transfer with a callback, it must be considered aborted prematurely by the code to avoid QUIT etc to be attempted as that would cause a hang. The new test case 1507 verifies this behavior. Reported by: Patricia Muscalu Bug: http://curl.haxx.se/bug/view.cgi?id=1184
2013-02-08 07:48:56 -05:00
lib1507_SOURCES = lib1507.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1507_LDADD = $(TESTUTIL_LIBS)
lib1507_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1507
Fix NULL pointer reference when closing an unused multi handle.
2013-02-10 16:57:58 -05:00
lib1508_SOURCES = lib1508.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1508_LDADD = $(TESTUTIL_LIBS)
lib1508_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1508
Multiple pipelines and limiting the number of connections. Introducing a number of options to the multi interface that allows for multiple pipelines to the same host, in order to optimize the balance between the penalty for opening new connections and the potential pipelining latency. Two new options for limiting the number of connections: CURLMOPT_MAX_HOST_CONNECTIONS - Limits the number of running connections to the same host. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished, so we can reuse the connection. CURLMOPT_MAX_TOTAL_CONNECTIONS - Limits the number of connections in total. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished. The free connection will then be reused, if possible, or closed if the pending handle can't reuse it. Several new options for pipelining: CURLMOPT_MAX_PIPELINE_LENGTH - Limits the pipeling length. If a pipeline is "full" when a connection is to be reused, a new connection will be opened if the CURLMOPT_MAX_xxx_CONNECTIONS limits allow it. If not, the handle will be put in a pending state until a connection is ready (either free or a pipe got shorter). CURLMOPT_CONTENT_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a transfer with a content length that is larger than this. CURLMOPT_CHUNK_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a chunk larger than this. CURLMOPT_PIPELINING_SITE_BL - A blacklist of hosts that don't allow pipelining. CURLMOPT_PIPELINING_SERVER_BL - A blacklist of server types that don't allow pipelining. See the curl_multi_setopt() man page for details.
2013-02-15 05:50:45 -05:00
test1509: verify proxy header response headers count Modified sws to support and use custom CONNECT responses instead of the previously naive hard-coded version. Made the HTTP test server able to extract test case number from the host name in a CONNECT request by finding the number after the last dot. It makes 'machine.moo.123' use test case 123. Adapted a larger amount of tests to the new <connect> style. Bug: http://curl.haxx.se/bug/view.cgi?id=1204 Reported by: Martin Jansen
2013-03-15 12:28:32 -04:00
lib1509_SOURCES = lib1509.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1509_LDADD = $(TESTUTIL_LIBS)
lib1509_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1509
easy: Fix the broken CURLOPT_MAXCONNECTS option Copy the CURLOPT_MAXCONNECTS option to CURLMOPT_MAXCONNECTS in curl_easy_perform(). Bug: http://curl.haxx.se/bug/view.cgi?id=1212 Reported-by: Steven Gu
2013-04-04 04:33:39 -04:00
lib1510_SOURCES = lib1510.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1510_LDADD = $(TESTUTIL_LIBS)
lib1510_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1510
tests: add test1511 to check timecond clean-up Verifies the timecond fix in commit c49ed0b6c0f
2013-04-22 14:07:15 -04:00
lib1511_SOURCES = lib1511.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1511_LDADD = $(TESTUTIL_LIBS)
lib1511_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1511
global dns cache: didn't work [regression] CURLOPT_DNS_USE_GLOBAL_CACHE broke in commit c43127414d89ccb (been broken since the libcurl 7.29.0 release). While this option has been documented as deprecated for almost a decade and nobody even reported this bug, it should remain functional. Added test case 1512 to verify
2013-08-08 07:01:16 -04:00
lib1512_SOURCES = lib1512.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1512_LDADD = $(TESTUTIL_LIBS)
lib1512_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1512
test1513: added - verify early progress callback return fail Verify the change brought in commit 8e11731653061. It makes sure that returning a failure from the progress callback even very early results in the correct return code.
2014-01-03 06:25:09 -05:00
lib1513_SOURCES = lib1513.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1513_LDADD = $(TESTUTIL_LIBS)
lib1513_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1513
test1514: added - no more negative Content-Length (HTTP POST) This covers changes from commit afd288b2.
2014-01-19 17:25:32 -05:00
lib1514_SOURCES = lib1514.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1514_LDADD = $(TESTUTIL_LIBS)
lib1514_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1514
tests: add test for bug #1303 (dns cache timeout) Test-case 1515 reproduces bug #1303, where libcurl would incorrectly prune DNS entries added via CURLOPT_RESOLVE after the DNS_CACHE_TIMEOUT had expired.
2014-01-31 14:03:13 -05:00
lib1515_SOURCES = lib1515.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1515_LDADD = $(TESTUTIL_LIBS)
CURLOPT_PROXYHEADER: set headers for proxy-only Includes docs and new test cases: 1525, 1526 and 1527 Co-written-by: Vijay Panghal
2014-01-31 02:10:07 -05:00
lib1515_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1515
tests: added test1517 ... for checking ability to receive full HTTP response when POST request is used with slow read callback function. This test checks for bug #657 and verifies the work-around from 72d5e144fbc6. Closes #720
2016-03-17 13:04:20 -04:00
lib1517_SOURCES = lib1517.c $(SUPPORTFILES)
lib1517_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1517
Curl_follow: extract the Location: header field unvalidated ... when not actually following the redirect. Otherwise we return error for this and an application can't extract the value. Test 1518 added to verify. Reported-by: Pavel Pavlov Fixes #3340 Closes #3364
2018-12-11 10:08:51 -05:00
lib1518_SOURCES = lib1518.c $(SUPPORTFILES)
lib1518_CPPFLAGS = $(AM_CPPFLAGS)
tests: Added test for bug #1456
2014-12-28 07:12:09 -05:00
lib1520_SOURCES = lib1520.c $(SUPPORTFILES)
lib1520_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1520
tests/libtest: Add lib1521 to nodist_SOURCES Since 467da3af0, lib1521.c is generated instead of checked in. According to the commit message, the intention was to remove it from the tarball as well. However, it is still present when running make dist. To remove it, add it to nodist_lib1521_SOURCES. This also means there is no need for the manually added dist-rule in the Makefile. Also update CMakelists.txt to handle the fact that we now may have nodist_SOURCES.
2018-06-04 14:28:59 -04:00
nodist_lib1521_SOURCES = lib1521.c $(SUPPORTFILES)
test1521: fix out-of-tree builds, broken with 467da3af The test.h file is no longer in the same directory as the source file, so that directory needs to be added to the include path. Fixes #1627 Closes #1628
2017-06-29 15:34:05 -04:00
lib1521_CPPFLAGS = $(AM_CPPFLAGS) -I$(srcdir)
test1521: test *all* curl_easy_setopt options mk-lib1521.pl generates a test program (lib1521.c) that calls curl_easy_setopt() for every known option with a few typical values to make sure they work (ignoring the return codes). Some small changes were necessary to avoid asserts and NULL accesses when doing this. The perl script needs to be manually rerun when we add new options. Closes #1543
2017-06-05 05:57:47 -04:00
CURLINFO_SIZE_UPLOAD: fix missing counter update Adds test 1522 for verification. Reported-by: cjmsoregan Fixes #2847 Closes #2864
2018-08-10 07:57:50 -04:00
lib1522_SOURCES = lib1522.c $(SUPPORTFILES)
lib1522_CPPFLAGS = $(AM_CPPFLAGS)
test1523: basic test of CURLOPT_LOW_SPEED_LIMIT
2019-06-13 06:08:57 -04:00
lib1523_SOURCES = lib1523.c $(SUPPORTFILES)
lib1523_CPPFLAGS = $(AM_CPPFLAGS)
CURLOPT_PROXYHEADER: set headers for proxy-only Includes docs and new test cases: 1525, 1526 and 1527 Co-written-by: Vijay Panghal
2014-01-31 02:10:07 -05:00
lib1525_SOURCES = lib1525.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1525_LDADD = $(TESTUTIL_LIBS)
lib1525_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1525
lib1526_SOURCES = lib1526.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1526_LDADD = $(TESTUTIL_LIBS)
lib1526_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1526
lib1527_SOURCES = lib1527.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1527_LDADD = $(TESTUTIL_LIBS)
lib1527_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1527
tests: add test for bug #1303 (dns cache timeout) Test-case 1515 reproduces bug #1303, where libcurl would incorrectly prune DNS entries added via CURLOPT_RESOLVE after the DNS_CACHE_TIMEOUT had expired.
2014-01-31 14:03:13 -05:00
PROXYHEADER: send these headers in "normal" proxy requests too Updated the docs to clarify and the code accordingly, with test 1528 to verify: When CURLHEADER_SEPARATE is set and libcurl is asked to send a request to a proxy but it isn't CONNECT, then _both_ header lists (CURLOPT_HTTPHEADER and CURLOPT_PROXYHEADER) will be used since the single request is then made for both the proxy and the server.
2014-02-20 11:10:00 -05:00
lib1528_SOURCES = lib1528.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1528_LDADD = $(TESTUTIL_LIBS)
lib1528_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1528
tests: make sure CRLFs can't be used in URLs passed to proxy Bug: http://curl.haxx.se/docs/adv_20150108B.html
2014-12-25 17:51:43 -05:00
lib1529_SOURCES = lib1529.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1529_LDADD = $(TESTUTIL_LIBS)
lib1529_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1529
CURLOPT_OPENSOCKETFUNCTION: return error at once When CURL_SOCKET_BAD is returned in the callback, it should be treated as an error (CURLE_COULDNT_CONNECT) if no other socket is subsequently created when trying to connect to a server. Bug: http://curl.haxx.se/mail/lib-2015-06/0047.html
2015-06-08 18:22:02 -04:00
lib1530_SOURCES = lib1530.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1530_LDADD = $(TESTUTIL_LIBS)
lib1530_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1530
test1531: verify POSTFIELDSIZE set after add_handle Following the fix made in 903b6e05565bf.
2015-06-23 20:51:03 -04:00
lib1531_SOURCES = lib1531.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1531_LDADD = $(TESTUTIL_LIBS)
lib1531_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1531
easy: Reset all statistical session info in curl_easy_reset Bug: https://github.com/curl/curl/issues/1017 Reported-by: Jeroen Ooms
2016-09-17 01:48:20 -04:00
lib1532_SOURCES = lib1532.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1532_LDADD = $(TESTUTIL_LIBS)
lib1532_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1532
New libcurl option to keep sending on error Add the new option CURLOPT_KEEP_SENDING_ON_ERROR to control whether sending the request body shall be completed when the server responds early with an error status code. This is suitable for manual NTLM authentication. Reviewed-by: Jay Satiro Closes https://github.com/curl/curl/pull/904
2016-09-22 16:15:13 -04:00
lib1533_SOURCES = lib1533.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1533_LDADD = $(TESTUTIL_LIBS)
lib1533_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1533
easy: Initialize info variables on easy init and duphandle - Call Curl_initinfo on init and duphandle. Prior to this change the statistical and informational variables were simply zeroed by calloc on easy init and duphandle. While zero is the correct default value for almost all info variables, there is one where it isn't (filetime initializes to -1). Bug: https://github.com/curl/curl/issues/1103 Reported-by: Neal Poole
2016-11-05 23:05:52 -04:00
lib1534_SOURCES = lib1534.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1534_LDADD = $(TESTUTIL_LIBS)
lib1534_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1534
tests: Add some testcases for recent new features. Add missing tests for CURLINFO_SCHEME, CURLINFO_PROTOCOL, %{scheme}, and %{http_version} closes #1143
2016-11-25 16:32:32 -05:00
lib1535_SOURCES = lib1535.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1535_LDADD = $(TESTUTIL_LIBS)
lib1535_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1535
lib1536_SOURCES = lib1536.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1536_LDADD = $(TESTUTIL_LIBS)
lib1536_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1536
test1537: dedicated tests of the URL (un)escape API calls Closes #1530
2017-06-02 07:16:13 -04:00
lib1537_SOURCES = lib1537.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1537_LDADD = $(TESTUTIL_LIBS)
lib1537_CPPFLAGS = $(AM_CPPFLAGS)
test1538: verify the libcurl strerror API calls
2017-06-02 07:52:55 -04:00
lib1538_SOURCES = lib1538.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1538_LDADD = $(TESTUTIL_LIBS)
lib1538_CPPFLAGS = $(AM_CPPFLAGS)
pause: handle mixed types of data when paused When receiving chunked encoded data with trailers, and the write callback returns PAUSE, there might be both body and header to store to resend on unpause. Previously libcurl returned error for that case. Added test case 1540 to verify. Reported-by: Stephen Toub Fixes #1354 Closes #1357
2017-03-27 06:14:57 -04:00
lib1540_SOURCES = lib1540.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1540_LDADD = $(TESTUTIL_LIBS)
lib1540_CPPFLAGS = $(AM_CPPFLAGS)
test1541: threaded connection sharing The threaded-shared-conn.c example turned into test case. Only works if pthread was detected. An attempt to detect future regressions such as e3a53e3efb942a5 Closes #3687
2019-03-17 18:37:35 -04:00
lib1541_SOURCES = lib1541.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1541_LDADD = $(TESTUTIL_LIBS)
lib1541_CPPFLAGS = $(AM_CPPFLAGS)
PIPELINING_SERVER_BL: cleanup the internal list use The list was freed incorrectly since the llist refactor of cbae73e1dd959. Added test 1550 to verify that it works and avoid future regressions. Reported-by: Pascal Terjan Fixes #1584 Closes #1585
2017-06-18 11:54:55 -04:00
lib1550_SOURCES = lib1550.c $(SUPPORTFILES)
lib1550_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1517
url: make the original string get used on subsequent transfers ... since CURLOPT_URL should follow the same rules as other options: they remain set until changed or cleared. Added test 1551 to verify. Fixes #1631 Closes #1632 Reported-by: Pavel Rochnyak
2017-07-03 17:52:10 -04:00
lib1551_SOURCES = lib1551.c $(SUPPORTFILES)
lib1551_CPPFLAGS = $(AM_CPPFLAGS)
multi_cleanup: call DONE on handles that never got that ... fixes a memory leak with at least IMAP when remove_handle is never called and the transfer is abruptly just abandoned early. Test 1552 added to verify Detected by OSS-fuzz Assisted-by: Max Dymond Closes #1954
2017-10-05 19:11:17 -04:00
lib1552_SOURCES = lib1552.c $(SUPPORTFILES) $(TESTUTIL)
libtest: Add required test libraries for lib1552 and lib1553 They use $(TESTUTIL) and thus should use $(TESTUTIL_LIBS) too. This fixes build failures on Fedora 13. Closes #2006
2017-10-23 13:51:36 -04:00
lib1552_LDADD = $(TESTUTIL_LIBS)
multi_cleanup: call DONE on handles that never got that ... fixes a memory leak with at least IMAP when remove_handle is never called and the transfer is abruptly just abandoned early. Test 1552 added to verify Detected by OSS-fuzz Assisted-by: Max Dymond Closes #1954
2017-10-05 19:11:17 -04:00
lib1552_CPPFLAGS = $(AM_CPPFLAGS)
pingpong: return error when trying to send without connection When imap_done() got called before a connection is setup, it would try to "finish up" and dereffed a NULL pointer. Test case 1553 managed to reproduce. I had to actually use a host name to try to resolve to slow it down, as using the normal local server IP will make libcurl get a connection in the first curl_multi_perform() loop and then the bug doesn't trigger. Fixes #1953 Assisted-by: Max Dymond
2017-10-06 11:20:54 -04:00
lib1553_SOURCES = lib1553.c $(SUPPORTFILES) $(TESTUTIL)
libtest: Add required test libraries for lib1552 and lib1553 They use $(TESTUTIL) and thus should use $(TESTUTIL_LIBS) too. This fixes build failures on Fedora 13. Closes #2006
2017-10-23 13:51:36 -04:00
lib1553_LDADD = $(TESTUTIL_LIBS)
pingpong: return error when trying to send without connection When imap_done() got called before a connection is setup, it would try to "finish up" and dereffed a NULL pointer. Test case 1553 managed to reproduce. I had to actually use a host name to try to resolve to slow it down, as using the normal local server IP will make libcurl get a connection in the first curl_multi_perform() loop and then the bug doesn't trigger. Fixes #1953 Assisted-by: Max Dymond
2017-10-06 11:20:54 -04:00
lib1553_CPPFLAGS = $(AM_CPPFLAGS)
test1554: verify connection cache sharing
2017-11-04 12:23:32 -04:00
lib1554_SOURCES = lib1554.c $(SUPPORTFILES)
lib1554_CPPFLAGS = $(AM_CPPFLAGS)
TODO fixed: Detect when called from within callbacks Closes #2302
2018-02-10 09:13:15 -05:00
lib1555_SOURCES = lib1555.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1555_LDADD = $(TESTUTIL_LIBS)
lib1555_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1555
test1556: verify >16KB headers to the header callback
2018-02-16 04:12:46 -05:00
lib1556_SOURCES = lib1556.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1556_LDADD = $(TESTUTIL_LIBS)
lib1556_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1556
multi: fix crash due to dangling entry in connect-pending list Fixes #2677 Closes #2679
2018-06-22 23:11:26 -04:00
lib1557_SOURCES = lib1557.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1557_LDADD = $(TESTUTIL_LIBS)
lib1557_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1557
test1558: verify CURLINFO_PROTOCOL on file:// transfer Attempt to reproduce issue #3444. Closes #3447
2019-01-08 03:58:50 -05:00
lib1558_SOURCES = lib1558.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1558_LDADD = $(TESTUTIL_LIBS)
CURL_MAX_INPUT_LENGTH: largest acceptable string input size This limits all accepted input strings passed to libcurl to be less than CURL_MAX_INPUT_LENGTH (8000000) bytes, for these API calls: curl_easy_setopt() and curl_url_set(). The 8000000 number is arbitrary picked and is meant to detect mistakes or abuse, not to limit actual practical use cases. By limiting the acceptable string lengths we also reduce the risk of integer overflows all over. NOTE: This does not apply to `CURLOPT_POSTFIELDS`. Test 1559 verifies. Closes #3805
2019-04-29 02:00:49 -04:00
lib1559_SOURCES = lib1559.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1559_LDADD = $(TESTUTIL_LIBS)
URL-API See header file and man pages for API. All documented API details work and are tested in the 1560 test case. Closes #2842
2018-08-05 05:51:07 -04:00
lib1560_SOURCES = lib1560.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1560_LDADD = $(TESTUTIL_LIBS)
http: Implement trailing headers for chunked transfers This adds the CURLOPT_TRAILERDATA and CURLOPT_TRAILERFUNCTION options that allow a callback based approach to sending trailing headers with chunked transfers. The test server (sws) was updated to take into account the detection of the end of transfer in the case of trailing headers presence. Test 1591 checks that trailing headers can be sent using libcurl. Closes #3350
2018-12-06 04:18:03 -05:00
lib1591_SOURCES = lib1591.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1591_LDADD = $(TESTUTIL_LIBS)
lib1591_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1591
curl_multi_remove_handle() don't block terminating c-ares requests Added Curl_resolver_kill() for all three resolver modes, which only blocks when necessary, along with test 1592 to confirm curl_multi_remove_handle() doesn't block unless it must. Closes #3428 Fixes #3371
2018-12-14 16:18:22 -05:00
lib1592_SOURCES = lib1592.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1592_LDADD = $(TESTUTIL_LIBS)
lib1592_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1592
http: allow overriding timecond with custom header With CURLOPT_TIMECONDITION set, a header is automatically added (e.g. If-Modified-Since). Allow this to be replaced or suppressed with CURLOPT_HTTPHEADER. Fixes #4103 Closes #4109
2019-07-10 18:42:35 -04:00
lib1593_SOURCES = lib1593.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1593_LDADD = $(TESTUTIL_LIBS)
CURLINFO_RETRY_AFTER: parse the Retry-After header value This is only the libcurl part that provides the information. There's no user of the parsed value. This change includes three new tests for the parser. Ref: #3794
2019-08-06 05:30:08 -04:00
lib1594_SOURCES = lib1594.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1594_LDADD = $(TESTUTIL_LIBS)
lib1596_SOURCES = lib1594.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1596_LDADD = $(TESTUTIL_LIBS)
lib1596_CPPFLAGS = $(AM_CPPFLAGS) -DLIB1596
Multiple pipelines and limiting the number of connections. Introducing a number of options to the multi interface that allows for multiple pipelines to the same host, in order to optimize the balance between the penalty for opening new connections and the potential pipelining latency. Two new options for limiting the number of connections: CURLMOPT_MAX_HOST_CONNECTIONS - Limits the number of running connections to the same host. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished, so we can reuse the connection. CURLMOPT_MAX_TOTAL_CONNECTIONS - Limits the number of connections in total. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished. The free connection will then be reused, if possible, or closed if the pending handle can't reuse it. Several new options for pipelining: CURLMOPT_MAX_PIPELINE_LENGTH - Limits the pipeling length. If a pipeline is "full" when a connection is to be reused, a new connection will be opened if the CURLMOPT_MAX_xxx_CONNECTIONS limits allow it. If not, the handle will be put in a pending state until a connection is ready (either free or a pipe got shorter). CURLMOPT_CONTENT_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a transfer with a content length that is larger than this. CURLMOPT_CHUNK_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a chunk larger than this. CURLMOPT_PIPELINING_SITE_BL - A blacklist of hosts that don't allow pipelining. CURLMOPT_PIPELINING_SERVER_BL - A blacklist of server types that don't allow pipelining. See the curl_multi_setopt() man page for details.
2013-02-15 05:50:45 -05:00
lib1900_SOURCES = lib1900.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
Add extra libs for lib1900 and lib2033 test programs These are needed in cases where clock_gettime is used, from librt.
2013-04-15 05:14:30 -04:00
lib1900_LDADD = $(TESTUTIL_LIBS)
Multiple pipelines and limiting the number of connections. Introducing a number of options to the multi interface that allows for multiple pipelines to the same host, in order to optimize the balance between the penalty for opening new connections and the potential pipelining latency. Two new options for limiting the number of connections: CURLMOPT_MAX_HOST_CONNECTIONS - Limits the number of running connections to the same host. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished, so we can reuse the connection. CURLMOPT_MAX_TOTAL_CONNECTIONS - Limits the number of connections in total. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished. The free connection will then be reused, if possible, or closed if the pending handle can't reuse it. Several new options for pipelining: CURLMOPT_MAX_PIPELINE_LENGTH - Limits the pipeling length. If a pipeline is "full" when a connection is to be reused, a new connection will be opened if the CURLMOPT_MAX_xxx_CONNECTIONS limits allow it. If not, the handle will be put in a pending state until a connection is ready (either free or a pipe got shorter). CURLMOPT_CONTENT_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a transfer with a content length that is larger than this. CURLMOPT_CHUNK_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a chunk larger than this. CURLMOPT_PIPELINING_SITE_BL - A blacklist of hosts that don't allow pipelining. CURLMOPT_PIPELINING_SERVER_BL - A blacklist of server types that don't allow pipelining. See the curl_multi_setopt() man page for details.
2013-02-15 05:50:45 -05:00
lib1900_CPPFLAGS = $(AM_CPPFLAGS)
cookies: only save the cookie file if the engine is enabled Follow-up to 8eddb8f4259. If the cookieinfo pointer is NULL there really is nothing to save. Without this fix, we got a problem when a handle was using shared object with cookies and is told to "FLUSH" it to file (which worked) and then the share object was removed and when the easy handle was closed just afterwards it has no cookieinfo and no cookies so it decided to save an empty jar (overwriting the file just flushed). Test 1905 now verifies that this works. Assisted-by: Michael Wallner Assisted-by: Marcel Raad Closes #3621
2019-02-26 10:35:07 -05:00
lib1905_SOURCES = lib1905.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1905_LDADD = $(TESTUTIL_LIBS)
lib1905_CPPFLAGS = $(AM_CPPFLAGS)
test1906: verify CURLOPT_CURLU + CURLOPT_PORT usage Based-on-code-by: Poul T Lomholt
2019-04-11 05:28:11 -04:00
lib1906_SOURCES = lib1906.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
lib1906_LDADD = $(TESTUTIL_LIBS)
lib1906_CPPFLAGS = $(AM_CPPFLAGS)
Multiple pipelines and limiting the number of connections. Introducing a number of options to the multi interface that allows for multiple pipelines to the same host, in order to optimize the balance between the penalty for opening new connections and the potential pipelining latency. Two new options for limiting the number of connections: CURLMOPT_MAX_HOST_CONNECTIONS - Limits the number of running connections to the same host. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished, so we can reuse the connection. CURLMOPT_MAX_TOTAL_CONNECTIONS - Limits the number of connections in total. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished. The free connection will then be reused, if possible, or closed if the pending handle can't reuse it. Several new options for pipelining: CURLMOPT_MAX_PIPELINE_LENGTH - Limits the pipeling length. If a pipeline is "full" when a connection is to be reused, a new connection will be opened if the CURLMOPT_MAX_xxx_CONNECTIONS limits allow it. If not, the handle will be put in a pending state until a connection is ready (either free or a pipe got shorter). CURLMOPT_CONTENT_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a transfer with a content length that is larger than this. CURLMOPT_CHUNK_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a chunk larger than this. CURLMOPT_PIPELINING_SITE_BL - A blacklist of hosts that don't allow pipelining. CURLMOPT_PIPELINING_SERVER_BL - A blacklist of server types that don't allow pipelining. See the curl_multi_setopt() man page for details.
2013-02-15 05:50:45 -05:00
lib2033_SOURCES = libntlmconnect.c $(SUPPORTFILES) $(TESTUTIL) $(WARNLESS)
Add extra libs for lib1900 and lib2033 test programs These are needed in cases where clock_gettime is used, from librt.
2013-04-15 05:14:30 -04:00
lib2033_LDADD = $(TESTUTIL_LIBS)
Multiple pipelines and limiting the number of connections. Introducing a number of options to the multi interface that allows for multiple pipelines to the same host, in order to optimize the balance between the penalty for opening new connections and the potential pipelining latency. Two new options for limiting the number of connections: CURLMOPT_MAX_HOST_CONNECTIONS - Limits the number of running connections to the same host. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished, so we can reuse the connection. CURLMOPT_MAX_TOTAL_CONNECTIONS - Limits the number of connections in total. When adding a handle that exceeds this limit, that handle will be put in a pending state until another handle is finished. The free connection will then be reused, if possible, or closed if the pending handle can't reuse it. Several new options for pipelining: CURLMOPT_MAX_PIPELINE_LENGTH - Limits the pipeling length. If a pipeline is "full" when a connection is to be reused, a new connection will be opened if the CURLMOPT_MAX_xxx_CONNECTIONS limits allow it. If not, the handle will be put in a pending state until a connection is ready (either free or a pipe got shorter). CURLMOPT_CONTENT_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a transfer with a content length that is larger than this. CURLMOPT_CHUNK_LENGTH_PENALTY_SIZE - A pipelined connection will not be reused if it is currently processing a chunk larger than this. CURLMOPT_PIPELINING_SITE_BL - A blacklist of hosts that don't allow pipelining. CURLMOPT_PIPELINING_SERVER_BL - A blacklist of server types that don't allow pipelining. See the curl_multi_setopt() man page for details.
2013-02-15 05:50:45 -05:00
lib2033_CPPFLAGS = $(AM_CPPFLAGS) -DUSE_PIPELINING
Reference in New Issue Copy Permalink