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

[Eli Zaretskii <eliz@gnu.org>]

> From: Alain Schneble <a.s@realize.ch>
> Date: Mon, 29 Feb 2016 18:57:28 +0100
> Cc: j_l_domenech@yahoo.com, 22789@debbugs.gnu.org
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Alain Schneble <a.s@realize.ch> writes:
> >
> >> 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).
> >
> > We could just increase that limit.  It's currently set to 100, which is
> > a number that's taken from thin air, I think?  It should probably be a
> > time-based handshake limit instead -- try handshaking for, say, ten
> > seconds before giving up...
> 
> A time-based limit sounds like a good idea to me.  It could even be
> combined with a min-number-of-tries approach, like this:
> 
> if (TimeElapsed > Timeout && NumberOfTries > MinNumberOfTries) {
>    // give up...
> }

I already tried increasing the limit, it doesn't help: the new limit
is reached.  Interestingly, when the initial connection is made, for
the page itself, the handshake completes within 10 attempts.  But the
subsequent connections, presumably for images, don't succeed, for some
reason.

> But the point I tried to address is the following: /When/ shall we start
> with the handshake "series" and start counting the number of tries (or
> stopwatch)?  Don't you agree that with async sockets, it doesn't make
> much sense to start it before the socket is connected?  So we could just
> postpone it until then...  Otherwise, the number of handshake tries (or
> time elapsed) durnig the "socket not yet connected" are subtracted from
> the max number of tries (or timeout) granted.  Which I think is, well,
> at least imprecise...

I think we are looking in the wrong direction.  We need first to
understand why the connection(s) to download the images don't work.
Does anyone already have an idea why this happens?  If so, please
describe that.

Failing that, I came to a conclusion that I don't have a clear and
complete picture of what should happen when eww receives the page and
proceeds to downloading the images.  Lars, can you please describe
what eww does at this point, and how these downloads are expected to
work asynchronously?  You can describe what happens on GNU/Linux, if
that makes it easier.  In particular, what are the differences between
the initial connection to get the page (which works) and the
connections made to get the images (which don't work)?

There is also some disturbing signs in retrying GnuTLS handshake from
wait_reading_process_output -- I'm not sure the way that function
works, at least on Windows, is according to you expectations.  The
while loop there doesn't really spin all the time, did you know that?
Can you describe what you think should happen there for a connection
whose GnuTLS handshake is not yet complete?