Age | Commit message (Collapse) | Author |
|
|
|
Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705783
Reported-by: Ludovico Cavedon <cavedon@debian.org>
|
|
Commit 11332577b3cb removed the length check that was performed by the
old scanf() code.
|
|
Fixed an issue in parse_proxy(), introduced in commit 11332577b3cb,
where an empty username or password (For example: http://:@example.com)
would cause a crash.
|
|
|
|
|
|
Updated the naming convention of the login parameters to match those of
other functions.
|
|
Tidy up of variable names and comments in setstropt_userpwd() and
parse_login_details().
|
|
There is no need to perform separate clearing of data if a NULL option
pointer is passed in. Instead this operation can be performed by simply
not calling parse_login_details() and letting the rest of the code do
the work.
|
|
|
|
setstropt_userpwd() was calling setstropt() in commit fddb7b44a79d to
set each of the login details which would duplicate the strings and
subsequently cause a memory leak.
|
|
|
|
In addition to parsing the optional login options from the URL, added
support for parsing them from CURLOPT_USERPWD, to allow the following
supported command line:
--user username:password;options
|
|
Added bounds checking when searching for the separator characters within
the login string as this string may not be NULL terminated (For example
it is the login part of a URL). We do this in preference to allocating a
new string to copy the login details into which could then be passed to
parse_login_details() for performance reasons.
|
|
|
|
|
|
|
|
|
|
signed and unsigned type in conditional expression
|
|
Separated the parsing of login details from the processing of them in
parse_url_login() ready for use by setstropt_userpwd().
|
|
Re-factored these functions to reflect their new behaviour following the
addition of login options.
|
|
|
|
Standardised the naming of all perform based functions to be in the form
smtp_perform_something().
|
|
|
|
|
|
|
|
|
|
|
|
Updated the coding style, in this function, to be consistant with other
response functions rather then performing a hard return on failure.
|
|
Updated the coding style, in this function, to be consistent with other
response functions rather then performing a hard return on failure.
|
|
Standardised the naming of all perform based functions to be in the form
pop3_perform_something() following the changes made to IMAP.
|
|
|
|
|
|
Started to apply the same tidy up to the POP3 code as applied to the
IMAP code in the 7.30.0 release.
|
|
Added support for specifying the preferred authentication mechanism in
the URL as per Internet-Draft 'draft-earhart-url-smtp-00'.
|
|
... to use left-shifted values, like those defined in curl.h, rather
than 16-bit hexadecimal values.
|
|
|
|
Added support for specifying the preferred authentication type and SASL
mechanism in the URL as per RFC-2384.
|
|
Added support for specifying the preferred authentication mechanism in
the URL as per RFC-5092.
|
|
... to use left-shifted values, like those defined in curl.h, rather
than 16-bit hexadecimal values.
|
|
In preparation for the upcoming changes to IMAP, POP3 and SMTP added
preferred mechanism values.
|
|
As well as parsing the username and password from the URL, added support
for parsing the optional options part from the login details, to allow
the following supported URL format:
schema://username:password;options@example.com/path?q=foobar
This will only be used by IMAP, POP3 and SMTP at present but any
protocol that may be given login options in the URL will be able to
add support for them.
|
|
warning: unused variable 'smtp' introduced in commit 73cbd21b5ee6.
|
|
|
|
...instead of the 220 we otherwise expect.
Made the ftpserver.pl support sending a custom "welcome" and then
created test 1219 to verify this fix with such a 230 welcome.
Bug: http://curl.haxx.se/mail/lib-2013-02/0102.html
Reported by: Anders Havn
|
|
Accessing a file with an absolute path in the root dir but with no
directory specified was not handled correctly. This fix comes with four
new test cases that verify it.
Bug: http://curl.haxx.se/mail/lib-2013-04/0142.html
Reported by: Sam Deane
|
|
|
|
|
|
|
|
This ought to speed up additional TLS handshakes, at least in theory.
|