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.
