From 1a393f562509cc8ee04793e4a640534dda5491f3 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Thu, 26 Jun 2003 11:38:53 +0000 Subject: [PATCH] mention COOKIES, removed added entries, corrected the FPL-SSL link/reference --- docs/TODO | 47 ++++++----------------------------------------- 1 file changed, 6 insertions(+), 41 deletions(-) diff --git a/docs/TODO b/docs/TODO index f1fbb49be..88c632883 100644 --- a/docs/TODO +++ b/docs/TODO @@ -16,7 +16,7 @@ TODO know what cookies that are received. Pushing interface that calls a callback on each received cookie? Querying interface that asks about existing cookies? We probably need both. Enable applications to modify - existing cookies as well. + existing cookies as well. http://curl.haxx.se/dev/COOKIES * Make content encoding/decoding internally be made using a filter system. @@ -50,10 +50,6 @@ TODO requested. That is, the download should not even begin but be aborted immediately. - * Allow the http_proxy (and other) environment variables to contain user and - password as well in the style: http://proxyuser:proxypasswd@proxy:port - Berend Reitsma suggested. - LIBCURL - multi interface * Make sure we don't ever loop because of non-blocking sockets return @@ -82,46 +78,15 @@ TODO * Since USERPWD always override the user and password specified in URLs, we might need another way to specify user+password for anonymous ftp logins. - * An option to only download remote FTP files if they're newer than the local - one is a good idea, and it would fit right into the same syntax as the - already working http dito works (-z). It of course requires that 'MDTM' - works, and it isn't a standard FTP command. - * Add FTPS support with SSL for the data connection too. This should be made - according to the specs written in draft-murray-auth-ftp-ssl-08.txt, - "Securing FTP with TLS" - - * --disable-epsv exists, but for active connections we have no --disable-eprt - (or even --disable-lprt). + according to the specs written in draft-murray-auth-ftp-ssl-11.txt, + "Securing FTP with TLS", valid until September 27th 2003. + http://curl.haxx.se/rfc/draft-murray-auth-ftp-ssl-11.txt HTTP - * If the "body" of the POST is < MSS it really aught to be sent along with - the headers. More generally, if the last chunk of the POST body is < MSS, - it should be sent with the previous chunk (which may be the POST headers). - So long as any one send is larger than MSS (or there is only one send when - < MSS :), the Nagle Algorithm will not be a problem on any stack where - Nagle is implemented correctly. (pointed out by Rick Jones) - - * Authentication: NTLM. Support for that MS crap called NTLM - authentication. MS proxies and servers sometime require that. Since that - protocol is a proprietary one, it involves reverse engineering and network - sniffing. This should however be a library-based functionality. There are a - few different efforts "out there" to make open source HTTP clients support - this and it should be possible to take advantage of other people's hard - work. http://modntlm.sourceforge.net/ is one. There's a web page at - http://www.innovation.ch/java/ntlm.html that contains detailed reverse- - engineered info. - - * RFC2617 compliance, "Digest Access Authentication" A valid test page seem - to exist at: http://hopf.math.nwu.edu/testpage/digest/ And some friendly - person's server source code is available at - http://hopf.math.nwu.edu/digestauth/index.html Then there's the Apache - mod_digest source code too of course. It seems as if Netscape doesn't - support this, and not many servers do. Although this is a lot better - authentication method than the more common "Basic". Basic sends the - password in cleartext over the network, this "Digest" method uses a - challange-response protocol which increases security quite a lot. + * Digest, NTLM and GSS-Negotiate support for HTTP proxies. They all work + on direct-connections to the server. * Pipelining. Sending multiple requests before the previous one(s) are done. This could possibly be implemented using the multi interface to queue