[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22789: 25.1.50; In last master build https connections stop working
From: |
Alain Schneble |
Subject: |
bug#22789: 25.1.50; In last master build https connections stop working |
Date: |
Sat, 5 Mar 2016 19:27:09 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) |
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.
- bug#22789: 25.1.50; In last master build https connections stop working, (continued)
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/01
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/03/01
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/01
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/03/04
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/04
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/04
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/04
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/03/05
- bug#22789: 25.1.50; In last master build https connections stop working,
Alain Schneble <=
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/03/05
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/06
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/06
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/07
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/03/07
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/07
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/03/07
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/07
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/03/07
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/03/07