error code cleanup, use the new SEND/RECV errors

based on Jacky Lam's "HTTP 1.0 304-only" fix, this change makes a 304 reply
always stop reading after the headers no matter what 'close' is.

Fixes the problem Jacky Jam pointed out, where libcurl will "hang" for an
extra second after having downloaded headers-only

crlf replacement on uploads did not work. test case 128 was added just now
to make sure it remains functional.

copyright string (year) update

make sure we return CURLE_WRITE_ERROR if the write callback returned
an error, even if we were decoding a chunked-encoded transfer

2002

Ralph Mitchell's SSL problems made me notice that we didn't increase the
header byte counter properly

Andr�s Garc�a solved bug report #515228 by making sure the progress meter
is updated even if everything is read in one single pass, as the windows
functions apparantly does more often than ot

Andr�s Garc�a solved bug report #515228 by making sure the progress meter
is updated even if everything is read in one single pass, as the windows
functions apparantly does more often than other systems.

show more ...

Brent Beardsley found the content-type bug!

upload progress counter fix, removed the adjustable upload buffer size

Giaslas Georgios introduced CURLINFO_CONTENT_TYPE

bug report #508235 identified a non-working Location: following, and this
little fix seems to correct it. another case where we just returned and
didn't shut off the reading. This bug is intr

bug report #508235 identified a non-working Location: following, and this
little fix seems to correct it. another case where we just returned and
didn't shut off the reading. This bug is introduced in 7.9.3 due to the
new internal "order".

show more ...

Andr�s Garc�a found out that we didn't properly stop reading from a connection
after the headers on a HEAD request. This bug has been added in 7.9.3 and was
mnot present earlier.

modified to deal with the new non-blocking versions of Curl_read() and
Curl_write().

Curl_read() now returns a negative return code if EWOULDBLOCK or similar

removed silly check for >=0 of a supposedly unsigned value!

added proper breaks in the switch()

HTTP response 204 should be treated similar to 304, that is we must not
expect (nor read) any response-body

merged the multi-dev branch back into MAIN again

i'm soooo funny

Georg Horn's STARTTRANSFER_TIME patch

we use signal() to ignore signals only as long as we have to, and we now
restore the previous (if any) signal handler properly on return.

myalarm() is history, we now use HAVE_ALARM and we now do our very best to
1 - restore the previous sigaction struct as soon as we are about to shut
off our timeout
2 - restore the previo

myalarm() is history, we now use HAVE_ALARM and we now do our very best to
1 - restore the previous sigaction struct as soon as we are about to shut
off our timeout
2 - restore the previous alarm() timeout, in case an application or similar
had it running before we "borrowed" it for a while.

No, this does not fix the multi-thread problem you get with alarm(). This
patch should correct bug report #478780:
//sourceforge.net/tracker/?func=detail&atid=100976&aid=478780&group_id=976

If not, please post details!

show more ...

failf() now only overwrites the error buffer the first time it gets called
for each *_perform(). It makes things a lot easier, as the first one that
detects the error get to write the final e

failf() now only overwrites the error buffer the first time it gets called
for each *_perform(). It makes things a lot easier, as the first one that
detects the error get to write the final error reason...

show more ...