I can't add comments to bug #3419270 so I'm creating a new entry to add my thoughts.
Looking at the HTTP headers sent back by gtk-gnutella, I see that Phex issues a follow-up request after a first successful transfer, but that follow-up causes the disconnection by Phex.
The probable reason is that gtk-gnutella does not always sends the "X-Gnutella-Content-URN" header back, especially when it is short on outgoing bandwidth and the issuer of the request sent an N2R GET requesst: the SHA1 is known by the requester, there's no doubt about the reply coming for that SHA1. The header was mandatory in the past when resources were requested by file index, along with the X-Gnutella-Content-URN header to tell the server about the SHA1.
But nowadays, modern Gnutella servents send N2R requests bearing the SHA1 and therefore the need to enforce X-Gnutella-Content-URN has disappeared. It's usually sent by gtk-gnutella the first time, but subsequent follow-up replies don't need to specify that header.
Phex should not choke on a missing X-Gnutella-Content-URN in the reply when it requests a file by N2R. But if it does, then it's the probable cause for the bug that was reported.
Thanks for analyzing and clarifying the problem. You were right with your assumption. I fixed it and it should work with the next build.
I just tested it with gtk-gnutella 0.97.1 and Phex 3.4.2.116 as described in the initial bug report and it's now working like a charm. Thank you guys!