>> FWIW, if Polipo can detect such a situation (either because we haven't >> reached the Content-Length the server declared, or because there was >> an unterminated chunk), it will refetch the object.
> The responses in question are completely empty, there's not a > single HTTP header and of course the nothingness isn't chunked > either. Then you should get a « 502 Server dropped connection » error. If you don't, please report it as a bug. > I get the impression that Polipo forwards them as empty page > and puts some headers on top. This shouldn't happen -- unless Polipo's immediate upstream happens to be an HTTP/1.0 implementation. (Even if the upstream is HTTP/1.0, this should only happen if the upstream sends no Content-Length *and* the connection is broken just after the CR-LF-CR-LF that ends the headers.) Please let me state this once more. HTTP/1.0 is obsolete, it is slow, it is unreliable. I've done my best to make HTTP/1.0 reasonably reliable in Polipo, but there's really not much that one can hack around with such a deficient protocol. (Note that, since HTTP/1.1 is backwards compatible with 1.0, it is possible to send an HTTP/1.0 reply with an HTTP/1.1 header.) > At least I'm currently running Privoxy->Polipo->Tor as default proxy chain Then don't do that. Privoxy is downgrading perfectly good HTTP/1.1 replies down to the old, unreliable, HTTP/1.0 kind. (Note that it does tag them with « HTTP/1.1 », which it is perfectly allowed to do.) Tested with Privoxy 3.0.6. > Refreshing with CTRL+F5 usually results in the real page. Yes, there's a special hack to ensure that objects served as HTTP/1.0 are less sticky than normal. (File server.c line 2086.) Juliusz