to the docs.

"http://somehost?data" as it added a slash too much in the request ("GET
/?data/"...). Added test case 260 to verify.

or the test is skipped. Ideally, we should let this test case go over a few
frequently used IPv6 localhost aliases...

A) Normal non-proxy HTTP:

 - no more "Pragma: no-cache" (this only makes sense to proxies)

B) Non-CONNECT HTTP request over proxy:

 - "Pragma: no-cache" is used (like before)
 - "Proxy-Connection: Keep-alive" (for older style 1.0-proxies)

C) CONNECT HTTP request over proxy:

 - "Host: [name]:[port]"
 - "Proxy-Connection: Keep-alive"

HTTP test server is a bit limited though, as it never responds to the POST
request until all data has been sent (and received)...

the runtests.pl to check this differently on operating systems that
differentiate on this.

.netrc, and when following a Location: the subsequent requests didn't properly
use the auth as found in the netrc file. Added test case 257 to verify my fix.

used the default port. He was right. I fixed the problem and added the test
cases 521, 522 and 523 to verify the fix.

libcurl didn't properly send an Expect: 100-continue header. It does now.

level stuff. The FTP server communicates with sockfilt using perl's open2().
This enables easier IPv6 support and hopefully FTP-SSL support in the future.
Added four test cases for FTP-ipv6.

kind of tests we have and how many tests that test certain features

when the response come in many small chunks.

CURLOPT_SSL_CTX_FUNCTION (yet).

also affecting NTLM and Negotiate.) It turned out that if the server responded
with 100 Continue before the initial 401 response, libcurl didn't take care of
the response properly. Test case 245 and 246 added to verify this.

But this works just fine on my host. Plain HTTP POST using Digest.

function was fixed to use the proper proxy authentication when multiple ones
were added as accepted. test 239 and test 243 were added to repeat the
problems and verify the fixes.

is no longer only present when built with SSL support.

on a host with a buggy resolver that strips all but the bottom 8 bits of
each octet.  The resolved address in this case (192.0.2.127) is guaranteed
never to belong to a real host (see RFC3330).

between platforms

but using illegal values

with a wildcard DNS search domain.

different values for it...

file got a Last-Modified: header written to the data stream, corrupting the
actual data. This was because some conditions from the previous FTP code was
not properly brought into the new FTP code. I fixed and I added test case 520
to verify. (This bug was introduced in 7.13.1)