Follow-up to 82245ea: Fix the example program sendrecv.c (handle
CURLE_AGAIN, handle incomplete send). Improve the documentation
for curl_easy_recv() and curl_easy_send().
Reviewed-by: Frank Meier
Assisted-by: Jay Satiro
See https://github.com/curl/curl/pull/1134
We're mostly saying just "curl" in lower case these days so here's a big
cleanup to adapt to this reality. A few instances are left as the
project could still formally be considered called cURL.
All plain C examples now (mostly) adhere to the curl code style. While
they are only examples, they had diverted so much and contained all
sorts of different mixed code styles by now. Having them use a unified
style helps users and readability. Also, as they get copy-and-pasted
widely by users, making sure they're clean and nice is a good idea.
573 checksrc warnings were addressed.
pop3-multi.c:96:5: warning: implicit declaration of function 'memset'
imap-multi.c:96:5: warning: implicit declaration of function 'memset'
http2-download.c:226:5: warning: implicit declaration of function 'memset'
http2-upload.c:290:5: warning: implicit declaration of function 'memset'
http2-upload.c:290:5: warning: implicit declaration of function 'memset'
Prior to this change any-domain cookies (cookies without a domain that
are sent to any domain) were exported with domain name "unknown".
Bug: https://github.com/bagder/curl/issues/292
- update default versions of dependencies (except for rare/old platforms)
- update urls
- sync examples makefiles with main ones
- remove line ending space
The function "free" is documented in the way that no action shall occur for
a passed null pointer. It is therefore not needed that a function caller
repeats a corresponding check.
http://stackoverflow.com/questions/18775608/free-a-null-pointer-anyway-or-check-first
This issue was fixed by using the software Coccinelle 1.0.0-rc24.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
For consistency, as we seem to have a bit of a mixed bag, changed all
instances of ipv4 and ipv6 in comments and documentations to use the
correct case.
For getting the date header its not necessary to access special
pages or even CGI scripts - all pages including the main index
reply with the date header, therefore shortened URLs to domain.
Removed worldtime.com; added pool.ntp.org.
Some websites meanwhile refuse to reply to requests from ancient
browsers like IE6, therefore I've comment out this setting, but
also fixed the string to now fake IE8 if someone enables it.
Prior to this change the 10-at-a-time example showed CURLE_RECV_ERROR
for the sony website because it ends the connection when the request is
missing a user agent.
Prior to this change when no file descriptors were ready on platforms
other than Windows the multi examples would sleep whatever was in
timeout, which may or may not have been less than the minimum
recommended value [1] of 100ms.
[1]: http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
Windows does not support using select() for sleeping without a dummy
socket. Instead use Windows' Sleep() and sleep for 100ms which is the
minimum suggested value in the curl_multi_fdset() doc.
Prior to this change the multi examples would exit prematurely since
select() would error instead of sleeping when called without an fd.
Reported-by: Johan Lantz
Bug: http://curl.haxx.se/mail/lib-2014-11/0221.html
This is just fundamentally broken. SPNEGO (RFC4178) is a protocol which
allows client and server to negotiate the underlying mechanism which will
actually be used to authenticate. This is *often* Kerberos, and can also
be NTLM and other things. And to complicate matters, there are various
different OIDs which can be used to specify the Kerberos mechanism too.
A SPNEGO exchange will identify *which* GSSAPI mechanism is being used,
and will exchange GSSAPI tokens which are appropriate for that mechanism.
But this SPNEGO implementation just strips the incoming SPNEGO packet
and extracts the token, if any. And completely discards the information
about *which* mechanism is being used. Then we *assume* it was Kerberos,
and feed the token into gss_init_sec_context() with the default
mechanism (GSS_S_NO_OID for the mech_type argument).
Furthermore... broken as this code is, it was never even *used* for input
tokens anyway, because higher layers of curl would just bail out if the
server actually said anything *back* to us in the negotiation. We assume
that we send a single token to the server, and it accepts it. If the server
wants to continue the exchange (as is required for NTLM and for SPNEGO
to do anything useful), then curl was broken anyway.
So the only bit which actually did anything was the bit in
Curl_output_negotiate(), which always generates an *initial* SPNEGO
token saying "Hey, I support only the Kerberos mechanism and this is its
token".
You could have done that by manually just prefixing the Kerberos token
with the appropriate bytes, if you weren't going to do any proper SPNEGO
handling. There's no need for the FBOpenSSL library at all.
The sane way to do SPNEGO is just to *ask* the GSSAPI library to do
SPNEGO. That's what the 'mech_type' argument to gss_init_sec_context()
is for. And then it should all Just Work™.
That 'sane way' will be added in a subsequent patch, as will bug fixes
for our failure to handle any exchange other than a single outbound
token to the server which results in immediate success.
Simplified the SMTP multi example as this example should demonstrate
the differences the easy and multi interfaces rather than introduce new
concepts such as user authentication and TLS which are shown in the TLS
and SSL examples.
Replaced the use of CURLOPT_USERPWD for the preferred CURLOPT_USERNAME
and CURLOPT_PASSWORD options and used the same username and password for
all email examples which is the same as that used in the test suite.
1) Renamed curl_tlsinfo to curl_tlssessioninfo as discussed on the
mailing list.
2) Renamed curl_ssl_backend to curl_sslbackend so it doesn't follow our
function naming convention.
3) Updated sessioninfo.c example accordingly.
"Dan Fandrich" <dan@coneharvesters.com> wrote:
>> But I'm not sure <unistd.h> is needed at all.
>
> It's needed for close(2). But the only reason that's needed is because fstat
> is used instead of stat(2); if you fix that, then you could remove that
> include altogether.
Okay. I've tested the following with MSVC and MingW. htttput.c now
simply uses stat():
CURLOPT_XFERINFOFUNCTION is now the preferred progress callback function
and CURLOPT_PROGRESSFUNCTION is considered deprecated.
This new callback uses pure 'curl_off_t' arguments to pass on full
resolution sizes. It otherwise retains the same characteristics: the
same call rate, the same meanings for the arguments and the return code
is used the same way.
The progressfunc.c example is updated to show how to use the new
callback for newer libcurls while supporting the older one if built with
an older libcurl or even built with a newer libcurl while running with
an older.
No more use exit(3) but instead tell libcurl that no byte has been
written to let it return a `CURLE_WRITE_ERROR`. In addition, check
curl easy handle return code.
This commit renames lib/setup.h to lib/curl_setup.h and
renames lib/setup_once.h to lib/curl_setup_once.h.
Removes the need and usage of a header inclusion guard foreign
to libcurl. [1]
Removes the need and presence of an alarming notice we carried
in old setup_once.h [2]
----------------------------------------
1 - lib/setup_once.h used __SETUP_ONCE_H macro as header inclusion guard
up to commit ec691ca3 which changed this to HEADER_CURL_SETUP_ONCE_H,
this single inclusion guard is enough to ensure that inclusion of
lib/setup_once.h done from lib/setup.h is only done once.
Additionally lib/setup.h has always used __SETUP_ONCE_H macro to
protect inclusion of setup_once.h even after commit ec691ca3, this
was to avoid a circular header inclusion triggered when building a
c-ares enabled version with c-ares sources available which also has
a setup_once.h header. Commit ec691ca3 exposes the real nature of
__SETUP_ONCE_H usage in lib/setup.h, it is a header inclusion guard
foreign to libcurl belonging to c-ares's setup_once.h
The renaming this commit does, fixes the circular header inclusion,
and as such removes the need and usage of a header inclusion guard
foreign to libcurl. Macro __SETUP_ONCE_H no longer used in libcurl.
2 - Due to the circular interdependency of old lib/setup_once.h and the
c-ares setup_once.h header, old file lib/setup_once.h has carried
back from 2006 up to now days an alarming and prominent notice about
the need of keeping libcurl's and c-ares's setup_once.h in sync.
Given that this commit fixes the circular interdependency, the need
and presence of mentioned notice is removed.
All mentioned interdependencies come back from now old days when
the c-ares project lived inside a curl subdirectory. This commit
removes last traces of such fact.
