bug#32658: gnutls + non-blocking url-retrieve

[Noam Postavsky <npostavs@gmail.com>]

thomas@m3y3r.de writes:

>>>> From: thomas@m3y3r.de
>>>> 
>>>> 1.) I needed to revert to gnutls 3.5.19, the mingw64 build from the
>>>> gitlab ci build seems to have a working gnutls-cli tools on windows 10.
>>>> the gitlab builds for 3.6.3 and 3.6.4 seems to have another bug
>>>> (error code -53) in the gnutls-cli command.
>>>> 
>>>> so only gnutls 3.5.19 have a working gnutls-cli. i installed this version in emacs 26.1

> okay, some more infos.
>
> I was able to bootstrap the emacs compile with mingw64.
>
> while I was trying to debug this problem with fprintf, eww suddenly
> started to work!!
>
> It started to work after I did insert an fprintf after the
> gnutls_try_handshake call in process.c !!
>
> what is going on here?

It sounds like this might be Bug#34341, the problem was
emacs_gnutls_read didn't handle GNUTLS_E_AGAIN properly.  The symptoms
only seem to occur with servers supporting TLS1.3 and more recent gnutls
versions (I thought it was 3.6+, but I haven't pinned the precise
version numbers, so maybe 3.5.19 has it too, or maybe it's a bit
different on Windows).  And some people reported that increasing
gnutls-log-level made it go away, so it's certainly timing dependent.

So can you check if the problem is fixed in the latest emacs-26 or
master branch?

https://debbugs.gnu.org/34341