| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Curl_posttransfer is called too soon to add the final new line.
Moved the new line logic to pgrsDone as there is no more call to
update the progress status after this call.
Reported by: Dmitri Shubin <sbn_at_tbricks.com>
http://curl.haxx.se/mail/lib-2010-12/0162.html
|
|
When libcurl sends a HTTP request on a re-used connection and detects it
being closed (ie no data at all was read from it), it is important to
rewind if any data in the request was sent using the read callback or
was read from file, as otherwise the retried request will be broken.
Reported by: Chris Smowton
Bug: http://curl.haxx.se/bug/view.cgi?id=3195205
|
|
The PROT_* set of internal defines for the protocols is no longer
used. We now use the same bits internally as we have defined in the
public header using the CURLPROTO_ prefix. This is for simplicity and
because the PROT_* prefix was already used duplicated internally for a
set of KRB4 values.
The PROTOPT_* defines were moved up to just below the struct definition
within which they are used.
|
|
The protocol handler struct got a 'flags' field for special information
and characteristics of the given protocol.
This now enables us to move away central protocol information such as
CLOSEACTION and DUALCHANNEL from single defines in a central place, out
to each protocol's definition. It also made us stop abusing the protocol
field for other info than the protocol, and we could start cleaning up
other protocol-specific things by adding flags bits to set in the
handler struct.
The "protocol" field connectdata struct was removed as well and the code
now refers directly to the conn->handler->protocol field instead. To
make things work properly, the code now always store a conn->given
pointer that points out the original handler struct so that the code can
learn details from the original protocol even if conn->handler is
modified along the way - for example when switching to go over a HTTP
proxy.
|
|
As we know how much to send, we can and should stop once we've sent that
much data as it avoids having to rely on other mechanisms to detect the
end.
This is one of the problems detected by test 582.
Reported by: Henry Ludemann <misc@hl.id.au>
|
|
|
|
This will be used by file_do() and Curl_readwrite() as a unified method
of checking to see if a remote document meets the supplied
CURLOPT_TIMEVAL and CURLOPT_TIMECONDITION.
Signed-off-by: Dave Reisner <d@falconindy.com>
|
|
As the function doesn't really use the connectdata struct but only the
SessionHanadle struct I modified what argument it wants.
|
|
Make sure that Curl_cache_addr() errors are propagated to callers of
loadhostpairs().
(this loadhostpairs function caused a scan-build warning due to the
'dns' variable getting assigned but never used)
|
|
It helps to prevent a hangup with some FTP servers in case idle session
timeout has exceeded. But it may be useful also for other protocols
that send any quit message on disconnect. Currently used by FTP, POP3,
IMAP and SMTP.
|
|
CURLOPT_RESOLVE is a new option that sends along a curl_slist with
name:port:address sets that will populate the DNS cache with entries so
that request can be "fooled" to use another host than what otherwise
would've been used. Previously we've encouraged the use of Host: for
that when dealing with HTTP, but this new feature has the added bonus
that it allows the name from the URL to be used for TLS SNI and server
certificate name checks as well.
This is a first change. Surely more will follow to make it decent.
|
|
Rodric provide an awesome recipe that proved libcurl didn't timeout at
the requested time - it instead often timed out at [connect time] +
[timeout time] instead of the documented and intended [timeout time]
only. This bug was due to the code using the wrong base offset when
comparing against "now". I could also take the oppurtinity to simplify
the code by properly using of the generic help function for this:
Curl_timeleft.
Reported by: Rodric Glaser
Bug: http://curl.haxx.se/bug/view.cgi?id=3061535
|
|
The code reading chunked encoding attempts to rewind the code if it had
read more data than the chunky parser consumes. The rewinding can fail
and it will then cause an error. This change now makes the rewinding
only happen if pipelining is in use - as that's the only time it really
needs to be done.
Bug: http://curl.haxx.se/mail/lib-2010-08/0297.html
Reported by: Ron Parker
|
|
When a new transfer is about to start we now set the proper timeouts to
expire for the multi interface if they are set for the handle. This is a
follow-up bugfix to make sure that easy handles timeout properly when
the times expire and the multi interface is used. This also improves
curl_multi_timeout().
|
|
When libcurl internally decided to wait for a 100-continue header, there
was no call to the timeout function so there was no timeout callback
called when the multi_socket API was used and thus applications became
either completely wrong or at least ineffecient depending on how they
handled the situation. We now set a timeout to get triggered.
Reported by: Ben Darnell
Bug: http://curl.haxx.se/bug/view.cgi?id=3039744
|
|
There is an implicit conversion from "unsigned long" to "long";
rounding, sign extension, or loss of accuracy may result.
Fixed by an added typecast.
|
|
|
|
|
|
|
|
Howard Chu brought the bulk work of this patch that properly
moves out the sending and recving of data to the parts of the
code that are properly responsible for the various ways of doing
so.
Daniel Stenberg assisted with polishing a few bits and fixed some
minor flaws in the original patch.
Another upside of this patch is that we now abuse CURLcodes less
with the "magic" -1 return codes and instead use CURLE_AGAIN more
consistently.
|
|
This function could only return CURLE_OK and by changing it to
a void instead, we can simplify code all over.
|
|
|
|
This gives a smoother rate limitation performance by using
sub-second pauses and also taking the buffer sizes into
account.
|
|
Bob Richmond: There's an annoying situation where libcurl will
read new HTTP response data from a socket, then check if it's a
timeout if one is set. If the last packet received constitutes
the end of the response body, libcurl still treats it as a
timeout condition and reports a message like:
"Operation timed out after 3000 milliseconds with 876 out of 876
bytes received"
It should only a timeout if the timer lapsed and we DIDN'T
receive the end of the response body yet.
|
|
|
|
expressions
|
|
makes sure that when using sub-second timeouts, there's no final bad 1000ms
wait. Previously, a sub-second timeout would often make the elapsed time end
up the time rounded up to the nearest second (e.g. 1s for 200ms timeout)
|
|
|
|
possible loss of data
|
|
|
|
check for (excess > 0 && !k->ignorebody).
|
|
|
|
|
|
|
|
|
|
|
|
libcurl options for controlling what to get and how to receive posssibly
interleaved RTP data. Initial commit.
|
|
the need for the struct forward declaration from http.h which caused problems
with gcc 2.96 and quite frankly the parameter wasn't necessary anyway
|
|
it in smtp.c
|
|
sequences in uploaded data. The test server doesn't "decode" escaped dot-lines
but instead test cases must be written to take them into account. Added test
case 803 to verify dot-escaping.
|
|
|
|
|
|
See http://curl.haxx.se/mail/lib-2009-12/0107.html
|
|
|
|
a broken TLS server. However it does not happen if SSL version is selected
manually. The approach was originally taken from PSM. Kaspar Brand helped me
to complete the patch. Original bug reports:
https://bugzilla.redhat.com/525496
https://bugzilla.redhat.com/527771
|
|
|
|
the define CURL_MAX_HTTP_HEADER which is even exposed in the public header
file to allow for users to fairly easy rebuild libcurl with a modified
limit. The rationale for a fixed limit is that libcurl is realloc()ing a
buffer to be able to put a full header into it, so that it can call the
header callback with the entire header, but that also risk getting it into
trouble if a server by mistake or willingly sends a header that is more or
less without an end. The limit is set to 100K.
|
|
|
|
transfer.c for blocking. It is currently used only by SCP and SFTP protocols.
This enhancement resolves an issue with 100% CPU usage during SFTP upload,
reported by Vourhey.
|
