Age | Commit message (Collapse) | Author |
|
Previously, when a stream was closed with other than NGHTTP2_NO_ERROR
by RST_STREAM, underlying TCP connection was dropped. This is
undesirable since there may be other streams multiplexed and they are
very much fine. This change introduce new error code
CURLE_HTTP2_STREAM, which indicates stream error that only affects the
relevant stream, and connection should be kept open. The existing
CURLE_HTTP2 means connection error in general.
Ref: https://github.com/curl/curl/issues/659
Ref: https://github.com/curl/curl/pull/663
|
|
... but ignore EAGAIN if the stream has ended so that we don't end up in
a loop. This is a follow-up to c8ab613 in order to avoid the problem
d261652 was made to fix.
Reported-by: Jay Satiro
Clues-provided-by: Tatsuhiro Tsujikawa
Discussed in #750
|
|
|
|
Closes #750
|
|
|
|
As these two options provide identical functionality, the former for
SOCK5 proxies and the latter for HTTP proxies, merged the two options
together.
As such CURLOPT_SOCKS5_GSSAPI_SERVICE is marked as deprecated as of
7.49.0.
|
|
This value is set to TRUE or FALSE so should be a bool and not a long.
|
|
|
|
Following conversation on the libcurl mailing list.
|
|
...when GSS-API or Windows SSPI are not used.
|
|
|
|
|
|
|
|
|
|
|
|
Allow the service name to be overridden for DIGIST-MD5 and Kerberos 5
authentication in FTP, IMAP, POP3 and SMTP.
|
|
Calculate the service name and proxy service names locally, rather than
in url.c which will allow for us to support overriding the service name
for other protocols such as FTP, IMAP, POP3 and SMTP.
|
|
|
|
|
|
Closes #603
|
|
Closes #544
|
|
Closes #543
|
|
Closes #522
|
|
|
|
|
|
... as otherwise we might get stuck thinking there's no more data to
handle.
Reported-by: Damien Vielpeau
Fixes #737
|
|
|
|
|
|
mbedtls_ is the prefix used by the mbedTLS library itself so we should
avoid using that for our private functions.
|
|
|
|
This reverts commit 9c08b4f1e7eced5a4d3782a3e0daa484c9d77d21.
Didn't help. Caused problems.
Fixes #756
|
|
Make (most) example snippets use the example.com domain instead of the
random ones picked and used before. Some of those were probably
legitimate sites and some not. example.com is designed for this purpose.
|
|
The space character after the status code is mandatory, even if the
reason phrase is empty (see RFC 7230 section 3.1.2)
Closes #755
|
|
Closes #754
|
|
Thinking it might help to apply patches etc with git.
|
|
It's a bad idea to send your passwords anywhere, especially over HTTP.
Modified example to send a picture instead.
Fixes #752
|
|
Now sorted into categories and organized in the same style we do the
TODO document. It will make each issue linked properly on the
https://curl.haxx.se/docs/knownbugs.html web page.
The sections should make it easier to find issues and issues related to
areas of the reader's specific interest.
|
|
|
|
|
|
|
|
Included a summary of the checksrc.bat updates and combined two krb5
changes as they should have been implemented at the same time.
|
|
Reported-by: Michael Osipov
|
|
Bug: https://github.com/curl/curl/issues/536
Reported-by: eXeC64@users.noreply.github.com
|
|
Due to their age (we don't fully know if they actually remain) and lack
of detail - very few people will bother to find out what they're about
or work on them. If people truly still suffer from any of these, I
assume they will be reported again and then we'll deal with them.
72. "Pausing pipeline problems."
https://curl.haxx.se/mail/lib-2009-07/0214.html
70. Problem re-using easy handle after call to curl_multi_remove_handle
https://curl.haxx.se/mail/lib-2009-07/0249.html
68. "More questions about ares behavior".
https://curl.haxx.se/mail/lib-2009-08/0012.html
|
|
|
|
It turns out the google GFE HTTP/2 servers send a PING frame immediately
after a stream ends and its last DATA has been received by curl. So if
we don't drain that from the socket, it makes the socket readable in
subsequent checks and libcurl then (wrongly) assumes the connection is
dead when trying to reuse the connection.
Reported-by: Joonas Kuorilehto
Discussed in #750
|
|
|
|
|
|
|
|
|