I've just tarred up my Polipo tree and put it in
Please note that this is a beta version. In particular, I didn't
update the manual, and the only documentation for the new features is
Please note furthermore that the format of the on-disk cache has
changed. No confusion will happen if you keep your old cache (the new
version will simply ignore the old files, which will eventually
expire), but you might as well do a quick
rm -r /var/cache/polipo/*
I've been running this version for a week now, and I've run out of
bugs to fix. If you can live without documentation, I suggest that
you upgrade. (Tom, please don't package this version, though.)
Here's a summary of the new features:
1. New disk cache format
The old disk cache format was limited to 1 KB of headers, and was
somewhat wasteful of disk space for very small objects. The new disk
format is more flexible, and allows a variable gap between the headers
and the body; this allows using a null gap for very small objects
(less than one block), and a larger gap for objects that need to be
rewritten in place.
The new format should in principle be slightly faster than the old one
for typical usage, although I don't think the difference is
measurable. It will be somewhat slower in some pathological cases,
but I don't think they actually happen in practice. (For what it's
worth, Squid breaks horribly in said cases.)
2. Access control
With 0.8.4, the only form of access control is provided by the
proxyAddress variable; on a typical configuration, it allows listening
on localhost only, or on the Internet at large.
0.8.99.0 implements two forms of access control. First, it allows
access control based on the client address; this is done by setting
the variable allowedClients to a list of networks, for example
proxyAddress = ::0
allowedClients = 10.0.0.1/8, 2001:660:116:1:207:e9ff::/48
Note that IPv6-mapped addresses are normalised back to IPv4, so you
don't need to take care of the horror yourself.
The other form of access control implemented is HTTP ``basic''
authentication. It allows you to specify a username and a password
that a client needs to know in order to connect, for example:
authCredentials = "user:secret"
Please note that basic auth is horribly insecure; the password is sent
over the net in cleartext with *every* request, and there is no replay
protection whatsoever. There is another standard, digest authenti-
cation (RFC 2617), which is slightly more secure, and which I might
However, even digest authentication is not really secure; if you use
Polipo over the internet, I recommend you have it listen on the
loopback interface and use an ssh tunnel (see Section 3.8 in the
manual for an example).
3. The number of connections per server is now runtime configurable
In order to make the best use of the network resources, Polipo opens
just two connections to each server and uses pipelining rather than
opening multiple connections. In 0.8.4, the number 2 is hardwired; in
0.8.99, it can be configured with the variable serverSlots.
When a server doesn't support persistent connections, Polipo opens
more connections to it (4 by default). This number can be customised
Obviously, I'm hoping to get Polipo to dynamically adapt the number of
slots per server to the traffic it sees; for now, the configuration
provides an escape hatch for cases when the default policy is not
adequate (for example large downloads over a very fast link with a
small TCP window).
Things to do for 0.9:
1. implement 100-Continue;
2. implement the CONNECT method;
3. make the HTTP parser more permissive of broken servers;
4. don't rely on Posix filesystem semantics in the expiry code (for
them Cygwin people).
Things to do if I feel like it:
1. implement digest authentication;
2. change the in-memory data structures to handle very small objects better;
3. implement DNS failover;
3. implement parent proxy failover and load balancing (CARP?).