3.6 Tweaking server-side behaviour

The most important piece of information about a server is whether it supports persistent connections. If this is the case, Polipo will open at most serverSlots connections to that server (serverSlots1 if the server only implements HTTP/1.0), and attempt to pipeline; if not, Polipo will hit the server harder, opening up to serverMaxSlots connections.

Another use of server information is to decide whether to pipeline additional requests on a connection that already has in-flight requests. This is controlled by the variable pipelineAdditionalRequests; if it is false, no additional requests will be pipelined. If it is true, additional requests will be pipelined whenever possible. If it is maybe (the default), additional requests will only be pipelined following small requests, where a small request one whose download is estimated to take no more than smallRequestTime (default 5s).

Sometimes, a request has been pipelined after a request that prompts a very large reply from the server; when that happens, the pipeline needs be broken in order to reduce latency. A reply is large and will cause a pipeline to be broken if either its size is at least replyUnpipelineSize (default one megabyte) or else the server’s transfer rate is known and the body is expected to take at least replyUnpipelineTime to download (default 15s).

The variable maxPipelineTrain defines the maximum number of requests that will be pipelined in a single write (default 10). Setting this variable to a very low value might (or might not) fix interaction with some unreliable servers that the normal heuristics are unable to detect.

The variable maxSideBuffering specifies how much data will be buffered in a PUT or POST request; it defaults to 1500 bytes. Setting this variable to 0 may cause some media players that abuse the HTTP protocol to work.