remain in use as internal curl_off_t print formatting strings for the internal
*printf functions which still cannot handle print formatting string directives
such as "I64d", "I64u", and others available on MSVC, MinGW, Intel's ICC, and
other DOS/Windows compilers.
This reverts previous commit part which did:
FORMAT_OFF_T -> CURL_FORMAT_CURL_OFF_T
FORMAT_OFF_TU -> CURL_FORMAT_CURL_OFF_TU
the names of the curl_off_t formatting string directives now become
CURL_FORMAT_CURL_OFF_T and CURL_FORMAT_CURL_OFF_TU.
CURL_FMT_OFF_T -> CURL_FORMAT_CURL_OFF_T
CURL_FMT_OFF_TU -> CURL_FORMAT_CURL_OFF_TU
Remove the use of an internal name for the curl_off_t formatting string directives
and use the common one available from the inside and outside of the library.
FORMAT_OFF_T -> CURL_FORMAT_CURL_OFF_T
FORMAT_OFF_TU -> CURL_FORMAT_CURL_OFF_TU
"HttpOnly" feature introduced by Microsoft and apparently also supported by
Firefox: http://msdn2.microsoft.com/en-us/library/ms533046.aspx . HttpOnly
is now supported when received from servers in HTTP headers, when written to
cookie jars and when read from existing cookie jars.
CURLOPT_COOKIEFILE), add a cookie (with CURLOPT_COOKIELIST), tell it to
write the result to a given cookie jar and then never actually call
curl_easy_perform() - the given file(s) to read was never read but the
output file was written and thus it caused a "funny" result.
- While doing some tests for the bug above, I noticed that Firefox generates
large numbers (for the expire time) in the cookies.txt file and libcurl
didn't treat them properly. Now it does.
libcurl without cookie support. This is mainly useful if you want to build a
minimalistic libcurl with no cookies support at all. Like for embedded
systems or similar.
data as 'char *' and that makes us pass in negative values if there is 8bit
data in the string. Changing to unsigned causes too much warnings or too many
required typecasts to the normal string functions.
contain least 4096 bytes while libcurl only allowed 2047. I raised the limit
to 4999 now and made the used buffer get malloc()ed instead of simply
allocated on stack as before.
which turned up to be due to the number of dots in the 'domain'. I've now
made curl follow the the original netscape cookie spec less strict on that
part.
in memory, only add it when we save the cookie. This makes all tailmatching
and domain string matching internally a lot easier.
This was also the reason for a remaining bug I introduced in my overhaul.
o Save domains in jars like Mozilla does. It means all domains set in
Set-Cookie: headers are dot-prefixed.
o Save and use the 'tailmatch' field in the Mozilla/Netscape cookie jars (the
second column).
o Reject cookies using illegal domains in the Set-Cookie: line. Concerns
both domains with too few dots or domains that are outside the currently
operating server host's domain.
o Set the path part by default to the one used in the request, if none was
set in the Set-Cookie line.
