On Sun, Nov 15, 2009 at 12:10 AM, Sigbjorn Finne wrote:

...

I've got a tentative fix in for this, not disabling closing altogether (that wouldn't be compliant with Connection:close handling), but delaying0 it until EOF is reached...at least that's the intent. It may not be lazy enough, but I'm unable to verify either way right now.

If anyone's interested in testing, the repo contains the changes made --

git://code.galois.com/HTTPbis.git/

On Sun, Nov 15, 2009 at 12:52 AM, Valery V. Vorotyntsev wrote:

Thanks, Sigbjorn!

I'll test it this Monday (by running `cabal update' with new HTTP).

Sorry, Sigbjorn, it didn't work. I've installed HTTP-4000.0.9 (the git version) and rebuilt-reinstalled cabal-install with it. The problem persist: $ cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: premature end of compressed stream $ $ runhaskell proxy-POC.hs Content-Length: 1304519 bytes downloaded: 2408 proxy-POC.hs: user error (sizes differ) I've rolled back to patched HTTP-4000.0.8, the one with connection closing commented out in `sendHTTP_notify'. I need this proxy downloading thing to just work... * * * AFAIU, you cannot test HTTP operation over proxy server, can you? I'm not sure, but installing squid might help exposing the bug. And if you let me speculate a bit... What if we employ ByteString's hGetContents for reading from connection? `hGetContents' closes handle automatically upon reaching EOF[1]. And ByteString does buffering by itself, HTTP package would not need as many {read,write}Block, buffer{Get,Put}Block calls[2] as there are now. The code would be simpler with fewer places for our current bug to hide. [1] http://is.gd/4W9sp [2] http://is.gd/4W97Y This is just an idea, nothing more. -- Regards, vvv