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

[Alain Schneble <a.s@realize.ch>]

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: Fri, 4 Mar 2016 22:36:56 +0100
>> 
>> I have the impression that GnuTLS doesn't like it too much if we start
>> retrying the handshake many times before the socket is connected.  At
>> least on MS-Windows.  In nearly all of the cases of loading websites
>> with around 20 images, I observe arbitrary failures of
>> gnutls_try_handshake which usually end up with -10
>> GNUTLS_E_INVALID_SESSION.
>
> I think this warrants a question to GnuTLS developers.  We need to
> understand this before we devise a solution.  What bothers me is the
> "many times" part -- how many is "too much", and why?

Yes, of course, I agree we have to understand it.  I just thought that
maybe the patch would help us in narrowing down the issue further...
And maybe we should wait until somebody else sees the same effects I
described on MS-Windows before asking GnuTLS developers?  Did you see
these problems as well?

I should have written "multiple times" not "many times".  I just had a
case where for four network processes (get image requests)
gnutls_try_handshake returned for each of these processes -28
GNUTLS_E_AGAIN three times in a row, followed by a single -110
GNUTLS_E_PREMATURE_TERMINATION and then repeatedly by -10
GNUTLS_E_INVALID_SESSION.

>                                                        Do you see any
> difference in behavior of sys_write during those many attempts as
> opposed to the first few?

Good point.  I'll have to analyze this.

> Also, what URL do you use for testing this?

Because I'm on MS-Windows, I used https://www.microsoft.com :)  (it gets
redirected to https://www.microsoft.com/de-ch for me).  I currently only
have access to a WLAN not under my control.  But the same Website loads
reliably and pretty fast in other web browsers with the same connection.

>> I believe this because the following patch solves the issue on my
>> MS-Windows system: Postponing the handshake until after the socket is
>> connected.  Still, I must be honest: I'm in a kind of a trial-and-error
>> mode.  I do not really understand all the aspects of the current
>> implementation.
>
> Feel free to ask, I think I can answer any question about the Emacs
> part of this, but probably not about the GnuTLS part -- those we
> should ask on the GnuTLS mailing list.

Ok, thank you!  I'll be happy to ask, but I would like to spend some
more time to re-read the code once again and clean up my mind first.

>> Anyway, I think a change in that direction would
>> probably be a good thing.  Do you agree?  It eliminates all the
>> handshake-retries that would otherwise happen before the socket is
>> connected.
>
> Why is it needed only on Windows?  Why does it matter what reason
> causes the failure of a handshake?  We need to understand these
> aspects before we consider the solutions.

I'm currently unable to answer these questions.  I see that there are
many differencies in Emacs' "platform adaption layer" for w32 vs the
paths for GNU/Linux.  And I cannot see if and how the patch I sent could
be related to those differencies.  So I follow your advice and will try
to understand the /issue/ first.

>> BTW, `libgnutls-version' evaluates to 30408 on my MS-Windows.
>
> It's 30311 here, but I'm not sure this is a factor.  We are talking
> about basic functionality here.

Thanks.