aboutsummaryrefslogtreecommitdiff
path: root/docs/TODO
diff options
context:
space:
mode:
authorDaniel Stenberg <daniel@haxx.se>2003-06-26 11:38:53 +0000
committerDaniel Stenberg <daniel@haxx.se>2003-06-26 11:38:53 +0000
commit1a393f562509cc8ee04793e4a640534dda5491f3 (patch)
tree08f03e51183d8ee13e500830bec1066db113f1b5 /docs/TODO
parentd4951e837e4821b5f1092b302c8eaa9077b1201c (diff)
mention COOKIES, removed added entries, corrected the FPL-SSL link/reference
Diffstat (limited to 'docs/TODO')
-rw-r--r--docs/TODO47
1 files 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