-$Id: TODO,v 1.157 2017/03/08 13:11:15 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.
14) Allow to filter POST parameters.
-16) Filter SSL encrypted content as well.
-
- At the beginning we could use a unencrypted connection between
- client and Privoxy, and use an encrypted connection between
- Privoxy and the server.
-
- This should be good enough for most of the content the
- user would want to filter.
-
- Interested donors: 2.
-
19) enable-forward-fallback. Syntax? Suggested by K.R.
21) User Manual delivery doesn't accept multiple slashes. Should it?
Interested donors: 1.
-54) Move away from CVS to a more modern revision control system.
- The move to git is work in progress:
- https://sourceforge.net/p/ijbswa/mailman/message/34994343/
-
58) Move more template strings from the code into the actual templates.
59) Import the German template translation.
79) Evaluate pcre alternatives.
-80) Change FEATURE_EXTENDED_HOST_PATTERNS to support both
- extended and vanilla host patterns at the same time.
-
- Note that the requirement is to allow the user to decide
- if the domain pattern should be interpreted as regex or
- traditional host pattern and if it's not obvious that the
- user made any decision, default to the latter.
-
- Possible solutions would be:
-
- 1. An always-use-regex-domain-patterns config option
- 2. An enable-regex-domain-patterns-for-this-action-file option
- 3. An enable-regex-domain-patterns-for-this-action-file-until-the-user-says-otherwise option
- 4. A treat-the-domain-pattern-in-this-line-as-regex(-or-not) option
- 5. Combinations of the options above
-
- With 2+4, 3+4 or 2+3+4 being the preferences until
- further discussion.
-
82) Detect if the system time goes back in time let the user
know if it caused any connections to get closed.
that makes sense. Like #93, this could be useful as a workaround
for misconfigured setups.
-95) Support a non-standard client header in CONNECT requests that
- contains the URL of the requested resource, which is then treated
- like the request URL.
-
- This way the client could opt-in for path-based blocking of https
- requests. Given that the headers from the CONNECT request aren't
- forwarded to the destination server, an unencrypted URL should be
- acceptable if the client and Privoxy are running on the same system
- or in a trusted environment.
-
96) Filters should be easier to look up. Currently get_filter() has to
go through all filters and skip the filter types the caller isn't
interested in.
-98) When showing action section on the CGI pages, properly escape
+98) When showing action sections on the CGI pages, properly escape
line breaks so they can be copy&pasted into action files without
adjustments.
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.
122) Allow customized log messages.
-123) Evaluate if the voluntarily-disclose-session-keys option in Firefox
- (and other browsers) can be leveraged. Probably depends on #16.
-
124) Add support for the "lightweight OS capability and sandbox framework"
Capsicum. http://www.cl.cam.ac.uk/research/security/capsicum/
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
remaining connections and shut down. This would allow higher
uptime and make testing more convenient.
+154) Underline links in docs and cgi pages. More precisely,
+ don't mess with the browser defaults for link underlining.
+
+155) The sig_handler() shouldn't call log_error().
+ While it isn't known to cause actual problems in normal operation,
+ 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.
+
+160) Add keep-alive support with +https-inspection.
+
##########################################################################
Hosting wish list (relevant for #53)