### 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.