server through a proxy and have the remote https server port set using the
CURLOPT_PORT option, protocol gets reset to http from https after the first
request.
User defined URL was modified internally by libcurl and subsequent reuse of
the easy handle may lead to connection using a different protocol (if not
originally http).
I found that libcurl hardcoded the protocol to "http" when it tries to
regenerate the URL if CURLOPT_PORT is set. I tried to fix the problem as
follows and it's working fine so far
"case label value exceeds maximum value for type" and
"comparison is always false due to limited range of data type"
Both triggered when using a bool variable as the switch variable
in a switch statement and using enums for the case targets.
Check for lowercase 'bool' type at configuration stage. If not available
provide a suitable replacement with a type definition of 'unsigned char'
in setup_once.h
Move definitions of TRUE and FALSE to setup_once.h
fixing some bugs:
o Don't mix GET and POST requests in a pipeline
o Fix the order in which requests are dispatched from the pipeline
o Fixed several curl bugs with pipelining when the server is returning
chunked encoding:
* Added states to chunked parsing for final CRLF
* Rewind buffer after parsing chunk with data remaining
* Moved chunked header initializing to a spot just before receiving
headers
part of the official libcurl API http://curl.haxx.se/lxr/source/lib/README.curlx
The documented way of using them would be to use timeval.c as a source code file.
The above described method works very well when statically linking libcurl and
apps, curl tool, but has several drawbacks when you build a true shared
libcurl (i.e. Name space clash at linkage stage as functions are defined more
than once. Windows makefiles are not capable of handling this system of
source-level sharing)
So...
Now curlutil.h and curlutil.c define and implement cutil_tvnow and cutil_tvdiff
which replace curlx_tvnow and curlx_tvdiff for the curl tool. Doing this we
avoid the above described problems.
1) The maketgz script does not insert the timestamp in curlver.h,
it actually updates it. For CVS versions it is the "CVS" string.
2) testcurl.pl will always print the "date" string which represents
the moment the test build is run.
3) testcurl.pl may not print the "timestamp" string since the script
may end before it is printed out. (i.e. unable to update from CVS)
4) The "timestamp" string printed will be the same as the "date" one
unless one of the following conditions is met.
*) It is a tarball-based build. Timestamp will be creation time.
*) CVS update has been done. Timestamp will be end of CVS update.
for tarball-based tests and builds, the maketgz script inserts it when
the tarball is created. For CVS-based tests and builds the timestamp we
show is the current UTC build time as it is the CVS version timestamp.
In this way, all builds will have a valid source code timestamp which
isn't related to the moment the tests and build is performed, with the
exception of CVS-based ones which have the same "date" and "timestamp"
