[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: |
Mon, 29 Feb 2016 10:55:52 +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: 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.
- 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, Eli Zaretskii, 2016/02/27
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/02/28
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/02/28
- bug#22789: 25.1.50; In last master build https connections stop working, Lars Ingebrigtsen, 2016/02/28
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/02/28
- bug#22789: 25.1.50; In last master build https connections stop working, Lars Ingebrigtsen, 2016/02/28
- 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, Lars Ingebrigtsen, 2016/02/29
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/02/29
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/02/29
- bug#22789: 25.1.50; In last master build https connections stop working, Lars Ingebrigtsen, 2016/02/29
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/02/29
- bug#22789: 25.1.50; In last master build https connections stop working, Alain Schneble, 2016/02/29
- bug#22789: 25.1.50; In last master build https connections stop working, Lars Ingebrigtsen, 2016/02/29
- bug#22789: 25.1.50; In last master build https connections stop working, Eli Zaretskii, 2016/02/29
- bug#22789: 25.1.50; In last master build https connections stop working, Lars Ingebrigtsen, 2016/02/29
- bug#22789: 25.1.50; In last master build https connections stop working, Lars Ingebrigtsen, 2016/02/29