-$Id: TODO,v 1.159 2017/03/08 13:11:38 fabiankeil Exp $
-
Some Privoxy-related tasks, sorted by the time they
have been added, not by priority.
The latest version should be available at:
-http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/TODO
+https://www.privoxy.org/gitweb/?p=privoxy.git;a=blob_plain;f=TODO;hb=HEAD
There's work in progress to fund development on these items using
donations. If you want to donate, please have a look at:
-http://www.privoxy.org/faq/general.html#DONATE
+https://www.privoxy.org/faq/general.html#DONATE
1) Add more regression tests. Filters should be tested automatically
(variables too). Could probably reuse large parts of Privoxy-Filter-Test.
files, but only in w32log.c the tray icon is explicitly set.
The logging is inconsistent as well. For details see #3525694.
-105) Add support for socks authentication.
-
106) actionlist.h should be embedded in a way that causes less text
segment bloat.
running out of stack space, causing the kernel to kill Privoxy
ungracefully.
-121) Add HTTP/2 support. As a first step, incomming HTTP/1.x requests
+121) Add HTTP/2 support. As a first step, incoming HTTP/1.x requests
should be translated to outgoing HTTP/2 requests where possible
(and if desired by the user).
Interested donors: 1.
forward-override). Investigate and fix or document.
141) Port Privoxy to CloudABI, which, despite the name, is actually
- rather neet. https://github.com/NuxiNL/cloudlibc
+ rather neat. https://github.com/NuxiNL/cloudlibc
142) Remove or update the "internal" pcre version.
currently can result in client requests to config.privoxy.org on the
Internet which may not be desirable.
-149) Use poll() for socket selection so the number of sockets Privoxy
- can deal with isn't limited to FD_SETSIZE anymore.
-
150) Add blacklistd support.
151) Let the dok-tidy target work cross-platform without introducing
it's technically incorrect and causes crashes when running in
valgrind.
+156) Reject socks requests with an explicit error message similar
+ to the one used for ftp. Motivation:
+ https://lists.privoxy.org/pipermail/privoxy-users/2017-March/000195.html
+
+158) Use a single thread to wait for new requests on reused client connections.
+ Currently the thread that handles the first request on a connection
+ stays responsible for the client connect until it gets closed.
+ In case of lots of idle connections lots of waiting threads are used.
+ While it's conceivable that this ineffiency is irrelevant from a
+ performance point of view, using a single thread should reduce Privoxy's
+ memory footprint a bit which may be noticeable in case of multi-user setups
+ with hundreds of idle connections.
##########################################################################
Hosting wish list (relevant for #53)