runtime libs.

now contain the word "proxy" is the hostname is in fact a proxy. This will
help users detect situations when they mistakenly use a proxy.

(http://curl.haxx.se/bug/view.cgi?id=1299181) that identified a silly problem
with Content-Range: headers with the 'bytes' keyword written in a different
case than all lowercase! It would cause a segfault!

the modified FTPS negotiation change of August 19 2005. Thus, we revert the
change back to pre-7.14.1 status.

define SEC_ENTRY and thus fails unless this is done!

protocol sockets even if the resolved address may say otherwise

Should we do this for all targets?

have this check done on far too many places by now...

added. TODO: add them to docs. add TFTP server to test suite. add TFTP to
list of protocols whereever those are mentioned.

Kevin Lussier pointed this out!

for Windows, that could lead to an Access Violation when the multi interface
was used due to an issue with how the resolver thread was and was not
terminated.

docs/TODO

from the command line tool with --ignore-content-length. This will make it
easier to download files from Apache 1.x (and similar) servers that are
still having problems serving files larger than 2 or 4 GB. When this option
is enabled, curl will simply have to wait for the server to close the
connection to signal end of transfer. I wrote test case 269 that runs a
simple test that this works.

previously failed due to GnuTLS not allowing x509 v1 CA certs by default.

that made curl run fine in his end. The key was to make sure we do the
SSL/TLS negotiation immediately after the TCP connect is done and not after
a few other commands have been sent like we did previously. I don't consider
this change necessary to obey the standards, I think this server is pickier
than what the specs allow it to be, but I can't see how this modified
libcurl code can add any problems to those who are interpreting the
standards more liberally.

  CURLOPT_COOKIEFILE), add a cookie (with CURLOPT_COOKIELIST), tell it to
  write the result to a given cookie jar and then never actually call
  curl_easy_perform() - the given file(s) to read was never read but the
  output file was written and thus it caused a "funny" result.

- While doing some tests for the bug above, I noticed that Firefox generates
  large numbers (for the expire time) in the cookies.txt file and libcurl
  didn't treat them properly. Now it does.

site responds with bad HTTP response that doesn't contain any header at all,
only a response body, and the write callback returns 0 to abort the
transfer, it didn't have any real effect but the write callback would be
called once more anyway.

too big