Age | Commit message (Collapse) | Author |
|
This change introduces a generic way to provide binary data in setopt
options, called BLOBs.
This change introduces these new setopts:
CURLOPT_ISSUERCERT_BLOB, CURLOPT_PROXY_SSLCERT_BLOB,
CURLOPT_PROXY_SSLKEY_BLOB, CURLOPT_SSLCERT_BLOB and CURLOPT_SSLKEY_BLOB.
Reviewed-by: Daniel Stenberg
Closes #5357
|
|
... to avoid an OpenSSL bug that otherwise makes the CRL check to fail.
Reported-by: Michael Kaufmann
Fixes #5374
Closes #5376
|
|
Closes #4346
|
|
Closes #5320
|
|
Closes #5287
|
|
Closes #5173
|
|
Closes #5192
|
|
In libcurl, CURLINFO_CONDITION_UNMET is used to avoid writing to the
output file if the server did not transfered a file based on time
condition. In the same manner, getting a 304 HTTP response back from the
server, for example after passing a custom If-Match-* header, also
fulfill this condition.
Fixes #5181
Closes #5183
|
|
Reported by the new script 'scripts/copyright.pl'. The script has a
regex whitelist for the files that don't need copyright headers.
Removed three (mostly usesless) README files from docs/
Closes #5141
|
|
- Implement new option CURLSSLOPT_REVOKE_BEST_EFFORT and
--ssl-revoke-best-effort to allow a "best effort" revocation check.
A best effort revocation check ignores errors that the revocation check
was unable to take place. The reasoning is described in detail below and
discussed further in the PR.
---
When running e.g. with Fiddler, the schannel backend fails with an
unhelpful error message:
Unknown error (0x80092012) - The revocation function was unable
to check revocation for the certificate.
Sadly, many enterprise users who are stuck behind MITM proxies suffer
the very same problem.
This has been discussed in plenty of issues:
https://github.com/curl/curl/issues/3727,
https://github.com/curl/curl/issues/264, for example.
In the latter, a Microsoft Edge developer even made the case that the
common behavior is to ignore issues when a certificate has no recorded
distribution point for revocation lists, or when the server is offline.
This is also known as "best effort" strategy and addresses the Fiddler
issue.
Unfortunately, this strategy was not chosen as the default for schannel
(and is therefore a backend-specific behavior: OpenSSL seems to happily
ignore the offline servers and missing distribution points).
To maintain backward-compatibility, we therefore add a new flag
(`CURLSSLOPT_REVOKE_BEST_EFFORT`) and a new option
(`--ssl-revoke-best-effort`) to select the new behavior.
Due to the many related issues Git for Windows and GitHub Desktop, the
plan is to make this behavior the default in these software packages.
The test 2070 was added to verify this behavior, adapted from 310.
Based-on-work-by: georgeok <giorgos.n.oikonomou@gmail.com>
Co-authored-by: Markus Olsson <j.markus.olsson@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Closes https://github.com/curl/curl/pull/4981
|
|
- --url man page section
- libcurl-security.3 gets the full text
- CURLOPT_URL.3
Reported-by: Tim Sedlmeyer
|
|
Assisted-by: Jay Satiro
Follow-up to 6357a19ff29dac04
Closes #5036
|
|
Reviewed-by: Steve Holme
Closes #5005
|
|
to be in sync with the description above
Reported-by: Joonas Kuorilehto
Fixes #4943
Closes #4945
|
|
Prior to this change the example would try to import cookies from stdin,
which wasn't what was intended.
Reported-by: 3dyd@users.noreply.github.com
Fixes https://github.com/curl/curl/issues/4930
|
|
Assisted-by: Jay Satiro
Reported-by: Craig Andrews
Fixes #4909
Closes #4910
|
|
Not from generic non-GET to GET.
Reported-by: Andrius Merkys
Ref: #4859
Closes #4861
|
|
- Copy CURLOPT_SSL_OPTIONS.3 description to CURLOPT_PROXY_SSL_OPTIONS.3.
Prior to this change CURLSSLOPT_NO_PARTIALCHAIN was missing from the
CURLOPT_PROXY_SSL_OPTIONS description.
|
|
Introduces CURLOPT_MAIL_RCPT_ALLLOWFAILS.
Verified with the new tests 3002-3007
Closes #4816
|
|
Mentioned: https://curl.haxx.se/mail/lib-2020-01/0050.html
Closes #4814
|
|
... and refer to that file from from CURLOPT_COOKIEFILE.3 and
CURLOPT_COOKIELIST.3
Assisted-by: Jay Satiro
Reported-by: bsammon on github
Fixes #4805
Closes #4806
|
|
|
|
Reported-by: Paul Joyce
Fixes https://github.com/curl/curl/issues/4787
|
|
For compatibility with `fwrite`, the `CURLOPT_HEADERFUNCTION` callback
is passed two `size_t` parameters which, when multiplied, designate the
number of bytes of data passed in. In practice, CURL always sets the
first parameter (`size`) to 1.
This practice is also enshrined in documentation and cannot be changed
in future. The documentation states that the default callback is
`fwrite`, which means `fwrite` must be a suitable function for this
purpose. However, the documentation also states that the callback must
return the number of *bytes* it successfully handled, whereas ISO C
`fwrite` returns the number of items (each of size `size`) which it
wrote. The only way these numbers can be equal is if `size` is 1.
Since `size` is 1 and can never be changed in future anyway, document
that fact explicitly and let users rely on it.
Reported-by: Frank Gevaerts
Commit-message-by: Christopher Head
Ref: https://github.com/curl/curl/pull/2787
Fixes https://github.com/curl/curl/issues/4758
|
|
Prior to this change the EXAMPLE in the QUOTE/PREQUOTE/POSTQUOTE man
pages would not compile because a variable name was incorrect.
Reported-by: Bylon2@users.noreply.github.com
Fixes https://github.com/curl/curl/issues/4736
|
|
[skip ci]
|
|
Reported-by: sayrer on github
Closes #4262
[skip ci]
|
|
|
|
Closes #4655
|
|
Reported-by: Jeff Mears
Bug: https://curl.haxx.se/mail/lib-2019-12/0007.html
Closes #4667
|
|
(also for PROGRESSFUNCTION)
By returning this value from the callback, the internal progress
function call is still called afterward.
Closes #4599
|
|
Closes #4547
|
|
Prior to this change some users did not understand that the "request"
starts when the handle is added to the multi handle, or probably they
did not understand that some of those transfers may be queued and that
time is included in timeout.
Reported-by: Jeroen Ooms
Fixes https://github.com/curl/curl/issues/4486
Closes https://github.com/curl/curl/pull/4489
|
|
... just say that limiting operations risk aborting otherwise fine
working transfers. If that means seconds, minutes or hours, we leave to
the user.
Reported-by: Martin Gartner
Closes #4469
|
|
|
|
Closes #4410
|
|
|
|
|
|
Closes #4273
|
|
Suggested-by: Brandon Dong
Fixes #4250
Closes #4269
|
|
For a long time (since 7.28.1) we've returned error when setting the
value to 1 to make applications notice that we stopped supported the old
behavior for 1. Starting now, we treat 1 and 2 exactly the same.
Closes #4241
|
|
|
|
Follow-up to 98c3f148 that removed it from the header file
|
|
... instead of mentioning one in another place
|
|
There's no use for this anymore and it was never in a release.
Closes #4206
|
|
Even though it cannot fall-back to a lower HTTP version automatically. The
safer way to upgrade remains via CURLOPT_ALTSVC.
CURLOPT_H3 no longer has any bits that do anything and might be removed
before we remove the experimental label.
Updated the curl tool accordingly to use "--http3".
Closes #4197
|
|
This is only the libcurl part that provides the information. There's no
user of the parsed value. This change includes three new tests for the
parser.
Ref: #3794
|
|
Added the ability for the calling program to specify the authorisation
identity (authzid), the identity to act as, in addition to the
authentication identity (authcid) and password when using SASL PLAIN
authentication.
Fixes #3653
Closes #3790
NOTE: This commit was cherry-picked and is part of a series of commits
that added the authzid feature for upcoming 7.66.0. The series was
temporarily reverted in db8ec1f so that it would not ship in a 7.65.x
patch release.
Closes https://github.com/curl/curl/pull/4186
|
|
As the plan has been laid out in DEPRECATED. Update docs accordingly and
verify in test 1174. Now requires the option to be set to allow HTTP/0.9
responses.
Closes #4191
|
|
If using the read callback for HTTP_POST, and POSTFIELDSIZE is not set,
automatically add a Transfer-Encoding: chunked header, same as it is
already done for HTTP_PUT, HTTP_POST_FORM and HTTP_POST_MIME. Update
test 1514 according to the new behaviour.
Closes #4138
|