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

[Alain Schneble]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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
>> 
>> 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.

Thanks!

>> 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?

What I had in mind was to start the GnuTLS handshake (or even
gnutls_boot) only after the async socket has properly been connected.  I
just consulted the GnuTLS documentation and I understand now that what
you write above is indeed a supported GnuTLS scenario.  But I think it
is not an optimal one, because the number of TLS handshake retries will
then depend on the time it takes to setup the socket connection, IIUC
(see process.c: abort if p->gnutls_handshakes_tried >
GNUTLS_EMACS_HANDSHAKES_LIMIT).

>> 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.

Ok, I see.  Thanks.

>> 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.

Thanks.

> 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?

I guess it's not.  There are still some issues with the GnuTLS code
paths, I think.  I tried out the approach I proposed above, and it seems
to resolve this issue as well.  I'll try to arrange and propose a patch
to discuss in a follow up message.