for non-blocking sockets: now -1 means error or connection finished, 1 means data was read, and 0
means there is no data available now so need to wait for poll (new return value)
half-finished.
Note the the req struct used to be re-initialized AFTER reading pipeline data, so now that we
initialize it from the caller we must be careful not to overwrite the pipeline data.
Also we now need to handle the case where the buffer is already full when get_request is called -
previously this never happened as it was always called with an empty buffer and looped until done.
Now get_request is called in a loop, so the next step is to run the loop on a socket only when poll
signals it is readable.
I made "connmon" not get initialized properly before use, and I use the
big hammer and make sure we always clear the entire struct to avoid any
problem like this in the future.
This makes verifying easier and makes us more sure curl closes the
connection only at the correct point in time. Adjusted test 206 and 1008
accordingly and updated the docs for it.
I moved out the servercmd parsing into a its own function called
parse_servercmd() and made sure it gets used also when the test number
is extracted from CONNECT requests. It turned out sws didn't do that
previously!
Using this, the server will output in the protocol log when the
connection gets disconnected and thus we will verify correctly in the
test cases that the connection doesn't get closed prematurely. This is
important for example NTLM to work.
Documentation added to FILEFORMAT, test 503 updated to use this.
There's a new 'http-proxy' server for tests that runs on a separate port
and lets clients do HTTP CONNECT to other ports on the same host to
allow us to test HTTP "tunneling" properly.
Test cases now have a <proxy> section in <verify> to check that the
proxy protocol part matches correctly.
Test case 80, 83, 95, 275, 503 and 1078 have been converted. Test 1316
was added.
When, for a given test, server is instructed to close connection after
server reply we now wait a very small amount of time (50ms) before doing
so. This is done to allow client to, at least partially, read server
reply before getting an ECONNRESET.
The above is required to make test cases 1070, 1200, 1201 and 1202 pass
with Cygwin 1.5.X on W2K.
GOPHER test server closes connection after _every_ server-reply, as such,
at some point it could require a bigger time or using shutdown() before
a server-side initiated disconnection.
This delays between write operations, hopefully making it easier
to spot problems where libcurl doesn't flush the socket properly
before waiting for the next response.
"Connection: close" and actually close the connection after the
response-body, libcurl could still have outstanding data to send and it
would not properly notice this and stop sending. This caused weirdness and
sad faces. http://curl.haxx.se/bug/view.cgi?id=2080222
Note that there are still reasons to consider libcurl's behavior when
getting a >= 400 response code while sending data, as Craig Perras' note
"http upload: how to stop on error" specifies:
http://curl.haxx.se/mail/archive-2008-08/0138.html
by Ben Sutcliffe. The test when run manually shows a problem in curl,
but the test harness web server doesn't run the test correctly so it's
disabled for now.
server input and response request files of the test harness sws server.
Reintroduce, for test # 1001, the <postcheck> small delay. The delay is
needed even with the accelerated writing of server input and response
request files in test harness sws server.
http://curl.haxx.se/mail/lib-2008-04/0385.html
responded with a single status line and no headers nor body. Starting now, a
HTTP response on a persistent connection (i.e not set to be closed after the
response has been taken care of) must have Content-Length or chunked
encoding set, or libcurl will simply assume that there is no body.
To my horror I learned that we had no less than 57(!) test cases that did bad
HTTP responses like this, and even the test http server (sws) responded badly
when queried by the test system if it is the test system. So although the
actual fix for the problem was tiny, going through all the newly failing test
cases got really painful and boring.
