PuTTY semi-bug http-proxy-auth-wsaenotconn

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.

We've reproduced the reported failure; what goes wrong next appears to be entirely within the client machine (and not a problem with the behaviour of the proxy server):

• Before closing the old socket, PuTTY uses the WSAAsyncSelect call to ask Windows to stop sending activity notifications for it. (That's normal when it closes any socket.)
• After opening the new socket, PuTTY again uses WSAAsyncSelect to ask Windows to start sending notifications.
• But it happens that Windows reuses the old socket's SOCKET handle value for the new socket, presumably on the grounds that it's just been freed up. So the socket handle that we enable notifications for is the same one that we just disabled them for.
• Then we receive an FD_CLOSE notification for a socket handle matching the socket we've just opened. In fact it's a leftover notification from the old socket - but we can't tell the difference, because they have the same handle!

We're not sure how this isn't a bug in the Windows sockets API. We haven't yet thought of how to work around it.