Uses closed connection from a proxy (e.g. squid2)

[nomeata]

This is related to #14, which may have not been fixed properly. When using cabal update built with HTTP-4000.2.17 and using a squid2 proxy, I get cabal: does not exist. A friend of mine did some debugging and found out:

it seems that cabal does a GET http://hackage.haskell.org/packages/archive/00-index.tar.gz squid responds with a cache hit 301 and closes the connection. cabal tries to use pipelining and fails it doesn't try a new connection

It does not happen with squid3, or perl’s HTTP::Proxy.

[bergmark]

We have the same error when forwarding connections through spiped with Cabal built against the latest HTTP version.

[nomeata]

@bergmark: Thanks. Maybe spiped provides a simple way for the HTTP developers to reproduce out issues. Can you describe a simple local setup that exhibits the error? Preferably with HTTP directoy and not involving cabal-install? This might speed up the resolving of this ticket.

[bergmark]

I'll ask my colleagues about it tomorrow.

[hsenag]

Just to set expectations:

As far as I know HTTP has one active maintainer (me) and zero long-term developers. Here I use "maintainer" in the sense of merging patches, making releases, perhaps the odd minor fix particularly when a new GHC comes along, and "developer" in the sense of people spending significant amounts of time working on fixing bugs and developing new features.

A reliable repro case, would definitely be a significant step towards getting this fixed, but it'll still need someone to make the fix. Ideally a repro would be expressed as a self-contained addition to the test-suite, but this may be harder if it relies on external software such as spiped.

[psibi]

I have been debugging on the issue. Cabal receives a message like this:

proxy uri host: 127.0.0.1, port: :3129 Creating new connection to 127.0.0.1:3129 Received: HTTP/1.1 301 Moved Permanently Server: nginx/1.6.0 Date: Mon, 14 Jul 2014 06:26:44 GMT Content-Type: text/plain; charset=UTF-8 Location: /package/storable-record-0.0.3/storable-record-0.0.3.tar.gz Content-Length: 0 Age: 5 Via: 1.1 localhost.localdomain Connection: close

Whenever we see "close" messages in the response, we clean the connection pool using the isTCPConnectedTo function. But the problem here is, the isTCPConnectedTo doesn't return False even though we receive "close" message. Any pointers on how to tackle this problem ?

[bergmark]

To clarify here as well, this is a regression in HTTP-4000.2.17, 4000.2.16 does not have this problem.

[hsenag]

OK, hopefully tracking it down will be much easier then.

The main difference between 4000.2.17 and 4000.2.16 is that openTCPConnection_ was rewritten in commit 5c1c7ba9bd622c3a205d240c92bd4b1e8c941cfa. It's not immediately obvious to me why that would cause this problem, but would you be able to verify if that commit triggers the problem, or otherwise bisect to figure out which other commit is responsible?

[bergmark]

Yep, that's the offending commit!

[hsenag]

Hmm - not really obvious why that would cause the symptoms described above. Any chance of a script that reproduces the problem? Even if it relies on having spiped installed it'd at least help with debugging, if not automated testing.

[hsenag]

Also pinging @dermesser who wrote the commit - any thoughts about how it might be triggering this problem?

[nomeata]

Just a small bump, as I just ran into the problem of cabal: does not exist again.

[erikd]

I've hit this as well. Will try downgrading HTP.

[Blaisorblade]

The cabal-install error message is discussed in https://github.com/haskell/cabal/issues/1914 — cabal never prints a decent error message when there are any network problems, so I get the same symptoms with the earlier HTTP-4000.2.10.

$ http_proxy=http://127.0.0.1 cabal update
Downloading the latest package list from hackage.haskell.org
cabal: does not exist

where there's no proxy at http://127.0.0.1 (just detaching the network also fails). That issue is also discussed in http://www.yesodweb.com/blog/2015/06/cabals-does-not-exist-error-message. So, we indeed need a smaller testcase.

This ticket is about the more restricted problem with proxies, introduced with 5c1c7ba9bd622c3a205d240c92bd4b1e8c941cfa.

@psibi wrote:

But the problem here is, the isTCPConnectedTo doesn't return False even though we receive "close" message. Any pointers on how to tackle this problem ?

At that point, did the client side already react to close by closing the connection? Both sides are supposed to do that.

Regarding 5c1c7ba9bd622c3a205d240c92bd4b1e8c941cfa, there's a bunch of undocumented changes in there, and if anybody has the setup to debug this problem, it'd help to bisect those changes further. None of that should make a difference, but some does, and they interact with huge chunks of code.