Age | Commit message (Collapse) | Author |
|
If the multi handle's pending timeout is less than what is passed into
this function, it will now opt to use the shorter time anyway since it
is a very good hint that the handle wants to process something in a
shorter time than what otherwise would happen.
curl_multi_wait.3 was updated accordingly to clarify
This is the reason for bug #1224
Bug: http://curl.haxx.se/bug/view.cgi?id=1224
Reported-by: Andrii Moiseiev
|
|
... because there's an identical check right next to it so using the
operators in the check in the same order increases readability.
|
|
|
|
|
|
|
|
A single backslash in the content is not legal nroff syntax.
Reported and fixed by: Eric S. Raymond
Bug: http://curl.haxx.se/bug/view.cgi?id=1234
|
|
Reported and fixed by: Eric S. Raymond
Bug: http://curl.haxx.se/bug/view.cgi?id=1233
|
|
|
|
When sending the HTTP Authorization: header for digest, the user name
needs to be escaped if it contains a double-quote or backslash.
Test 1229 was added to verify
Reported and fixed by: Nach M. S
Bug: http://curl.haxx.se/bug/view.cgi?id=1230
|
|
SSL_read can return 0 for "not successful", according to the open SSL
documentation: http://www.openssl.org/docs/ssl/SSL_read.html
|
|
We found that in specific cases if the connection is abruptly closed,
the underlying socket is listed in a close_wait state. We continue to
call the curl_multi_perform, curl_mutli_fdset etc. None of these APIs
report the socket closed / connection finished. Since we have cases
where the multi connection is only used once, this can pose a problem
for us. I've read that if another connection was to come in, curl would
see the socket as bad and attempt to close it at that time -
unfortunately, this does not work for us.
I found that in specific situations, if SSL_write returns 0, curl did
not recognize the socket as closed (or errored out) and did not report
it to the application. I believe we need to change the code slightly, to
check if ssl_write returns 0. If so, treat it as an error - the same as
a negative return code.
For OpenSSL - the ssl_write documentation is here:
http://www.openssl.org/docs/ssl/SSL_write.html
|
|
Bug: http://curl.haxx.se/bug/view.cgi?id=1169
|
|
1 - don't skip host names with a colon in them in an attempt to bail out
on HTTP headers in the cookie file parser. It was only a shortcut anyway
and trying to parse a file with HTTP headers will still be handled, only
slightly slower.
2 - don't skip domain names based on number of dots. The original
netscape cookie spec had this oddity mentioned and while our code
decreased the check to only check for two, the existing cookie spec has
no such dot counting required.
Bug: http://curl.haxx.se/bug/view.cgi?id=1221
Reported-by: Stefan Neis
|
|
Explain the callback and its arguments better and with more descriptive
text.
|
|
|
|
|
|
Add an XML stream parsing example using Expat. Add missing ignore for
the binary from an unrelated example.
|
|
I found a bug which cURL sends cookies to the path not to aim at.
For example:
- cURL sends a request to http://example.fake/hoge/
- server returns cookie which with path=/hoge;
the point is there is NOT the '/' end of path string.
- cURL sends a request to http://example.fake/hogege/ with the cookie.
The reason for this old "feature" is because that behavior is what is
described in the original netscape cookie spec:
http://curl.haxx.se/rfc/cookie_spec.html
The current cookie spec (RFC6265) clarifies the situation:
http://tools.ietf.org/html/rfc6265#section-5.2.4
|
|
|
|
This reverts commit 8ec2cb5544b86306b702484ea785b6b9596562ab.
We don't have any code anywhere in libcurl (or the curl tool) that use
wcsdup so there's no such memory use to track. It seems to cause mild
problems with the Borland compiler though that we may avoid by reverting
this change again.
Bug: http://curl.haxx.se/mail/lib-2013-05/0070.html
|
|
|
|
|
|
|
|
Reported by: David Strauss
Bug: http://curl.haxx.se/mail/lib-2013-05/0088.html
|
|
|
|
Bug: http://curl.haxx.se/bug/view.cgi?id=1220
Patch by: John Gardiner Myers
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... and de-duplicate the code initializing *passphrase
|
|
|
|
|
|
|
|
|
|
comparison between signed and unsigned integer expressions
|
|
|
|
|
|
If the mail sent during the transfer contains a terminating <CRLF> then
we should not send the first <CRLF> of the EOB as specified in RFC-5321.
Additionally don't send the <CRLF> if there is "no mail data" as the
DATA command already includes it.
|
|
... which was missed in commit: f5c3d9538452
|
|
... which was missed in commit: f5c3d9538452
|
|
|
|
|
|
Introduced in commit: 514817669e9e
|
|
|
|
...and removed references to libcurl and test1406.
|