- May 12, 2016
-
-
Cory Benfield authored
curl's representation of HTTP/2 responses involves transforming the response to a format that is similar to HTTP/1.1. Prior to this change, curl would do this by separating header names and values with only a colon, without introducing a space after the colon. While this is technically a valid way to represent a HTTP/1.1 header block, it is much more common to see a space following the colon. This change introduces that space, to ensure that incautious tools are safely able to parse the header block. This also ensures that the difference between the HTTP/1.1 and HTTP/2 response layout is as minimal as possible. Bug: https://github.com/curl/curl/issues/797 Closes #798 Fixes #797
-
Kamil Dudka authored
... introduced in curl-7_48_0-293-g2968c83: Error: COMPILER_WARNING: lib/vtls/openssl.c: scope_hint: In function ‘Curl_ossl_check_cxn’ lib/vtls/openssl.c:767:15: warning: conversion to ‘int’ from ‘ssize_t’ may alter its value [-Wconversion]
-
Jay Satiro authored
- In the case of recv error, limit returning 'connection still in place' to EINPROGRESS, EAGAIN and EWOULDBLOCK. This is an improvement on the parent commit which changed the openssl connection check to use recv MSG_PEEK instead of SSL_peek. Ref: https://github.com/curl/curl/commit/856baf5#comments
-
- May 10, 2016
-
-
Anders Bakken authored
Calling SSL_peek can cause bytes to be read from the raw socket which in turn can upset the select machinery that determines whether there's data available on the socket. Since Curl_ossl_check_cxn only tries to determine whether the socket is alive and doesn't actually need to see the bytes SSL_peek seems like the wrong function to call. We're able to occasionally reproduce a connect timeout due to this bug. What happens is that Curl doesn't know to call SSL_connect again after the peek happens since data is buffered in the SSL buffer and thus select won't fire for this socket. Closes #795
-
- May 09, 2016
-
-
Daniel Stenberg authored
Only protocols that actually have a protocol registered for ALPN and NPN should try to get that negotiated in the TLS handshake. That is only HTTPS (well, http/1.1 and http/2) right now. Previously ALPN and NPN would wrongly be used in all handshakes if libcurl was built with it enabled. Reported-by: Jay Satiro Fixes #789
-
- May 08, 2016
-
-
Daniel Stenberg authored
-
Antonio Larrosa authored
Sometimes, in systems with both ipv4 and ipv6 addresses but where the network doesn't support ipv6, Curl_is_connected returns an error (intermittently) even if the ipv4 socket connects successfully. This happens because there's a for-loop that iterates on the sockets but the error variable is not resetted when the ipv4 is checked and is ok. This patch fixes this problem by setting error to 0 when checking the second socket and not having a result yet. Fixes #794
-
- May 05, 2016
-
-
Jay Satiro authored
-
- May 03, 2016
-
-
Daniel Stenberg authored
Reported-by: Oleg Pudeyev and fuchaoqun Fixes #648
-
- May 02, 2016
-
-
Daniel Stenberg authored
Reported-by: rcanavan Assisted-by: Isaac Boukris Closes #785
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
Closes #727
-
- May 01, 2016
-
-
Daniel Stenberg authored
-
Isaac Boukris authored
Mention possible content-length mismatch with sum of bytes reported by write callbacks when auto decoding is enabled. See #785
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Jay Satiro authored
- Move the existing scheme check from tool_operate. In the case of --remote-header-name we want to parse Content-disposition for a filename, but only if the scheme is http or https. A recent adjustment 0dc4d8e4 was made to account for schemeless URLs however it's not 100% accurate. To remedy that I've moved the scheme check to the header callback, since at that point the library has already determined the scheme. Bug: https://github.com/curl/curl/issues/760 Reported-by: Kai Noda
-
Daniel Stenberg authored
to make it obvious to users trying to use the feature with TLS backends not supporting it. Discussed in #781 Reported-by: Travis Burtrum
-
Daniel Stenberg authored
... not used by any test yet but can be used stand-alone.
-
Daniel Stenberg authored
-
Michael Kaufmann authored
Closes #786
-
Daniel Stenberg authored
As discussed in #785
-
- Apr 29, 2016
-
-
Daniel Stenberg authored
Reported-by: mgendre Closes #784
-
Karlson2k authored
Closes #675
-
Karlson2k authored
-
Karlson2k authored
-
Karlson2k authored
-
Daniel Stenberg authored
curl_printf.h defines printf to curl_mprintf, etc. This can cause problems with external headers which may use __attribute__((format(printf, ...))) markers etc. To avoid that they cause problems with system includes, we include curl_printf.h after any system headers. That makes the three last headers to always be, and we keep them in this order: curl_printf.h curl_memory.h memdebug.h None of them include system headers, they all do funny #defines. Reported-by: David Benjamin Fixes #743
-
Daniel Stenberg authored
Mostly because they're not needed, because memdebug.h is always included last of all headers so the others already included the correct ones. But also, starting now we don't want this to accidentally include any system headers, as the header included _before_ this header may add defines and other fun stuff that we won't want used in system includes.
-
Jay Satiro authored
It does open up a miniscule risk that one of the other protocols that libcurl could use would send back a Content-Disposition header and then curl would act on it even if not HTTP. A future mitigation for this risk would be to allow the callback to ask libcurl which protocol is being used. Verified with test 1312 Closes #760
-
- Apr 28, 2016
-
-
Daniel Stenberg authored
This script now also scans src/tool_getparam.c, docs/curl.1 and src/tool_help.c and will warn if any of them lists a command line option not mentioned in one of the other places.
-
Daniel Stenberg authored
-
Daniel Stenberg authored
In commit 2e42b0a2 (Jan 2008) we made the option "--socks" deprecated and it has not been documented since. The more explicit socks options (like --socks4 or --socks5) should be used.
-
Daniel Stenberg authored
-
Daniel Stenberg authored
It was mentioned as deprecated already in commit ae1912cb from 1999. It has not been documented in this millennium.
-