all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: thomas@m3y3r.de
Cc: 32658@debbugs.gnu.org
Subject: bug#32658: gnutls + non-blocking url-retrieve
Date: Mon, 01 Oct 2018 09:03:04 +0300	[thread overview]
Message-ID: <83efda431j.fsf@gnu.org> (raw)
In-Reply-To: <86tvm6smax.fsf@DESKTOP-DQBDJ0U.i-did-not-set--mail-host-address--so-tickle-me> (thomas@m3y3r.de)

> From: thomas@m3y3r.de
> Date: Sun, 30 Sep 2018 23:33:10 +0200
> 
> 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
> 
> 2.) testing gnutls stream
> using open-gnutls-stream directly gives me a correct tls connection but
> eww still fails to load the site.
> 
> when I change url-open-stream in url/url-gw.el to:
> 			  (open-network-stream
> 			   name buffer host service
> 			   :type gw-method
> 			   ;; Use non-blocking socket if we can.
>                           :nowait nil))
> 
> I finally can open lwn.net in eww.
> 
> so something seems to be wrong possible with blocking/non-blocking
> network access.
> 
> any ideas?

Thanks for the info.

First, I don't understand what does gnutls-cli have to do with this.
Emacs on Windows doesn't support TLS connections that use gnutls-cli,
because the way that works, it requires working support for signals,
which cannot happen on Windows.  Are you saying that these problems
happen when you use gnutls-cli?  If so, please move to the built-in
GnuTLS support, because connections using gnutls-cli are deprecated,
and I see no point in trying to support them on Windows.

Second, I cannot reproduce the problem you are reporting.  Using stock
Emacs 26.1 I built myself, with GnuTLS 3.4.15, I have no problems
connecting to lwn.net via eww.  I see EAGAIN errors like you do, but
they are non-fatal, so don't prevent the connection from continuing.
It is strange that you are having these problems, but maybe these
problems are specific to GnuTLS 3.6.x?  3.6.x is not a stable branch
of GnuTLS, it could have bugs, in particular bugs specific to Windows.
It is also possible that there are incompatibilities between GnuTLS
3.6.x and whatever version the Emacs binary you are using was built
against.

In this message you say that you downgraded to GnuTLS 3.5.19, but you
didn't show the gnutls.c log for that version -- does it mean you see
an identical problem with EAGAIN there?

Is it possible for you to downgrade GnuTLS to some version of the
3.4.x branch, and see if the problem persists?

Also, does this happen in "emacs -Q"?

Or maybe this is specific to your network connection?  Does any HTTPS
connection cause these problems?

Finally, what about other machines and/or Windows versions other than
10 -- do you have the same problem there with this Emacs version
(assuming you can test that)?

Bottom line: I'm surprised that you have these problems, because I see
none of that on my machines -- TLS connections "just work" for me,
without any need to tinker with url-gw.el or elsewhere.  And judging
by lack of similar bug reports, this also works for others.  So I
wonder what causes this in your case.





  reply	other threads:[~2018-10-01  6:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-07  9:22 bug#32658: 26.1; Cannot connect to TLS websites thomas
2018-09-30 21:33 ` bug#32658: gnutls + non-blocking url-retrieve thomas
2018-10-01  6:03   ` Eli Zaretskii [this message]
2018-10-01 20:48     ` thomas
2018-10-05 18:25       ` Noam Postavsky
2018-10-03 14:15     ` thomas
2018-10-07 13:42       ` thomas
2019-05-16 13:14         ` Noam Postavsky
2019-09-24  5:18           ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83efda431j.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=32658@debbugs.gnu.org \
    --cc=thomas@m3y3r.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.