bug#22789: 25.1.50; In last master build https connections stop working

[Eli Zaretskii]

> From: Alain Schneble <a.s@realize.ch>
> CC: <larsi@gnus.org>, <j_l_domenech@yahoo.com>, <22789@debbugs.gnu.org>
> Date: Sun, 28 Feb 2016 10:48:37 +0100
> 
> If I swap the order of the if statements in sys_write to look as
> follows, then the reason for the SOCKET_ERROR is revealed:
> 
>       if (nchars == SOCKET_ERROR)
>         {
>         DebPrint (("sys_write.send failed with error %d on socket %ld\n",
>                    pfn_WSAGetLastError (), SOCK_HANDLE (fd)));
>         set_errno ();
>       }
> 
>       /* Set the socket back to non-blocking if it was before,
>        for other operations that support it.  */
>       if (fd_info[fd].flags & FILE_NDELAY)
>       {
>         printf ("reset file_ndelay");
>         nblock = 1;
>         pfn_ioctlsocket (SOCK_HANDLE (fd), FIONBIO, &nblock);
>       }
> 
> => WSAENOTCONN (10057): Socket is not connected.  So that's the prove it
> accesses the socket too early.

Yes.

> Alas, even though it seems to help at least for the test code I tried,
> turning WSAENOTCONN into EAGAIN seems wrong after all.

It does here, although this needs to be done only if the socket is in
the process of connecting, and the return value needs to be negative,
not zero.  I installed a fix along these lines, and it seems to work
for me: https://www.fsf.org is displayed OK.

> It shouldn't try to write to the socket before it is connected at
> all...(?)

No, I think it should: that write comes from GnuTLS, when it attempts
a handshake.  Returning EWOULDBLOCK tells GnuTLS to spin waiting until
the connection is complete.  How else could this work, since we now
proceed with GnuTLS handshake immediately after the call to 'connect'
returns, when the connection is not yet complete, this being a
non-blocking socket?

> Also the code "wraps" pfn_send and turns it into a blocking call.
> Not sure what the implications are...

The only implication is that we get ENOTCONN instead of EWOULDBLOCK.
But that's easy to handle.

> Nevertheless, don't you think the error handling in this code section is
> not very elaborate and switching the order as shown above might be
> better anyway?  sys_write is primarily about writing, not about
> switching from non-blocking to blocking and back again...  Or shall it
> somehow aggregate possible errors of both calls (pfn_send and
> pfn_ioctlsocket)?

Yes, you are right.  I did that.

The only problem left is that not all images on www.fsf.org's page are
downloaded; they are if I use http instead of https.  I guess this is
some eww thing?