Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
We've had reports that, since 0.77, attempting to use PuTTY on Windows to connect via an HTTP proxy that requires authentication can fail, possibly intermittently, with the message "Network error: Socket is not connected".
This appears to have been triggered by the overhaul of PuTTY's HTTP proxy implementation in 0.77 to add features such as Digest authentication and interactive prompting, combined with the behaviour of certain proxy servers.
Since 0.77, when PuTTY first connects to an HTTP proxy server, it
initially doesn't attempt to send credentials at all, even if it has
them; this is intended to elicit a "407 Proxy Authentication Required"
response from the server if needed, along with
Proxy-Authenticate header(s) telling PuTTY which
authentication methods the server will accept. PuTTY will then try
again, this time providing credentials using the best available
authentication method.
(Previously, PuTTY would have eagerly sent any credentials it had
as plaintext HTTP Basic authentication right at the start, as that's
all it knew how to do; but that's no longer appropriate.)
Some proxy servers choose to close the HTTP connection immediately after telling the client the supported authentication methods (Connection: close). (A proxy server from "Bluecoat" is one such.) In this situation, PuTTY immediately opens a fresh connection to the proxy server, intending to send the credentials this time.
It turns out that the Windows API will often reuse the same socket id for the new connection that previously referred to the old one. This leads to a bug when leftover activity notifications for the old socket are still in PuTTY's internal queues, and it misinterprets them as referring to the new socket. The fix is to identify the notifications that refer to a closed socket, and either throw them away proactively, or recognise and ignore them when they arrive, whichever is easiest.
(This was previously documented as "surely a bug in Windows", in the belief that the Windows API itself was sending us notifications for the old socket even after its id had been reused. Now I don't believe that any more: I think the stale notifications had already been passed to PuTTY at the time the old socket was closed, so it's PuTTY's job to find them and either throw them away or ignore them.)