url-retrieve fails on most HTTPS sites

url-retrieve fails on most HTTPS sites

[Nicolas Graner]

Hello all,

using 26.1 on Debian, I try to open various web pages with url-retrieve.
It works with all HTTP and some HTTPS connections, but fails with most
HTTPS. For instance with Wikipedia:

  (switch-to-buffer (url-retrieve "https://wikipedia.org/" '(lambda (&rest ignore))))

The buffer that shows up is empty. Tracing url-http-async-sentinel gives:

======================================================================
1 -> (url-http-async-sentinel #<process wikipedia.org> "open
")
1 <- url-http-async-sentinel: nil
======================================================================
1 -> (url-http-async-sentinel #<process wikipedia.org> "connection broken by remote peer
")
1 <- url-http-async-sentinel: nil

In contrast, The Conversation is OK:
  (switch-to-buffer (url-retrieve "https://theconversation.com/fr/" '(lambda (&rest ignore))))
works fine, the buffer contains HTTP headers followed by à HTML page.

I don't use a proxy. The result is the same whether url-privacy-level
is 'none or 'paranoid.

Any suggestions as to what could make some sites close the connection,
or how I could find out more?

Thanx for your help.
Nicolas

Re: url-retrieve fails on most HTTPS sites

[Emanuel Berg via Users list for the GNU Emacs text editor]

Nicolas Graner wrote:

>   (switch-to-buffer (url-retrieve
> "https://wikipedia.org/" '(lambda (&rest ignore))))
>
> The buffer that shows up is empty.

Never heard of `url-retrieve' but I have it and yes,
what "shows up is empty".

(BTW, don't quote lambdas! was the rule one decade ago...)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: url-retrieve fails on most HTTPS sites

[2QdxY4RzWzUUiLuE]

On 2020-09-29 at 01:13:51 +0200,
Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> Nicolas Graner wrote:
> 
> >   (switch-to-buffer (url-retrieve
> > "https://wikipedia.org/" '(lambda (&rest ignore))))
> >
> > The buffer that shows up is empty.
> 
> Never heard of `url-retrieve' but I have it and yes,
> what "shows up is empty".

It works for me.  Sort of.

I ran (url-retrieve "https://wikipedia.org/" (lambda (&rest ignore))) in
my *scratch* buffer, and watched carefully.

    (url-retrieve
     "https://wikipedia.org/"
     (lambda (&rest ignore)))
    #<buffer  *http wikipedia.org:443*>

That buffer is empty.  But the buffer " *http www.wikipedia.org:443*"
contains the HTML I/we expected.

> (BTW, don't quote lambdas! was the rule one decade ago...)

From wrting too much Common Lisp, I'm used to writing #'(lambda ...),
but I'm not qualified to judge elisp.

Re: url-retrieve fails on most HTTPS sites

[Emanuel Berg via Users list for the GNU Emacs text editor]

Re: url-retrieve fails on most HTTPS sites
2QdxY4RzWzUUiLuE wrote:

> On 2020-09-29 at 01:13:51 +0200,
> Emanuel Berg via Users list for the GNU Emacs text
> editor <help-gnu-emacs@gnu.org> wrote:
>
>> Nicolas Graner wrote:
>> 
>> >   (switch-to-buffer (url-retrieve
>> > "https://wikipedia.org/" '(lambda (&rest ignore))))
>> >
>> > The buffer that shows up is empty.
>> 
>> Never heard of `url-retrieve' but I have it and yes,
>> what "shows up is empty".
>
> It works for me.  Sort of.
>
> I ran (url-retrieve "https://wikipedia.org/"
> (lambda (&rest ignore))) in my *scratch* buffer,
> and watched carefully.
>
     (url-retrieve
      "https://wikipedia.org/"
      (lambda (&rest ignore)))
     #<buffer  *http wikipedia.org:443*>

I search downwards for some sign, signals aren't
strong enough, perhaps?

>> (BTW, don't quote lambdas! was the rule one decade
>> ago...)
>
> From wrting too much Common Lisp, I'm used to
> writing #'(lambda ...), but I'm not qualified to
> judge elisp.

Comrade S Monnier always said don't quote lambdas.
and... I believed him.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: url-retrieve fails on most HTTPS sites

[Stefan Monnier]

>>> (BTW, don't quote lambdas! was the rule one decade ago...)
>> From wrting too much Common Lisp, I'm used to
>> writing #'(lambda ...), but I'm not qualified to
>> judge elisp.
> Comrade S Monnier always said don't quote lambdas.
> and... I believed him.

' and #' are two different beasts.  If you want to wrap your lambdas
inside #' be my guest.  But please don't quote them with ' because it
turns them into "lists which happen to look eerily like functions".
You can't α-rename lists, you can't byte-compile lists, you can't
macro-expand lists, you can't detect "bugs" or code smells in lists, ...


        Stefan

Re: url-retrieve fails on most HTTPS sites

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>>>>> (switch-to-buffer (url-retrieve
>>>>> "https://wikipedia.org/" '(lambda (&rest
>>>>> ignore))))
>>>>
>>>> (BTW, don't quote lambdas! was the rule one
>>>> decade ago...)
>>>
>>> From wrting too much Common Lisp, I'm used to
>>> writing #'(lambda ...), but I'm not qualified to
>>> judge elisp.
>>
>> Comrade S Monnier always said don't quote lambdas.
>> and... I believed him.
>
> ' and #' are two different beasts. If you want to
> wrap your lambdas inside #' be my guest.

As is evident from the level 5 cite above, the lambda
was _quoted_, I don't know how sharp quote entered
the discussion. Oh, I do know that, I just didn't
notice...

OK, with a quote, you make it a list, not a function.

And with a #', you make it a function.

But... isn't it already a function? As in "anonymous
function"?

In the Elisp manual [1] it says:

  The read syntax #' is a short-hand for using
  `function'. The following forms are all equivalent:

            (lambda (x) (* x x))
  (function (lambda (x) (* x x)))
          #'(lambda (x) (* x x))

So why use it?


[1] (info "(elisp) Anonymous Functions")
    http://www.gnu.org/software/emacs/manual/html_node/elisp/Anonymous-Functions.html

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: url-retrieve fails on most HTTPS sites

[tomas]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

On Tue, Sep 29, 2020 at 05:24:35AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:

[...]

> OK, with a quote, you make it a list, not a function.
> 
> And with a #', you make it a function.
> 
> But... isn't it already a function? As in "anonymous
> function"?

Yep.

If the thing following #' is a (lambda ...), then the #' is
redundant. We all know that is a function (it is harmless, though --
as far as redundant things can be considered harmless).

Things become more interesting if the thing coming after #'
is a symbol, like in #'car.

Then we all know we are talking about car's symbol-function.
This allows the human code readers and the compiler to be
smarter about the code.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: url-retrieve fails on most HTTPS sites

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

> Things become more interesting if the thing coming
> after #' is a symbol, like in #'car.

The use case, at least mine, is to denote functions
so the byte-compiler can check if they are defined.
Makes development faster and more pleasant...

Yeah ... what _is_ the origin/reason of this thing,
deep down? That symbols are not only a value or
a function but both, and more?

  symbol-function
  symbol-value
  ...

> Then we all know we are talking about car's
> symbol-function. This allows the human code readers
> and the compiler to be smarter about the code.

Yeah, however what gain is there to mucking with
that? That cannot be solved, or solved in a worse
way, with "dedicated symbols", I guess?

(Not a rhetorical question.)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: url-retrieve fails on most HTTPS sites

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

On Tue, Sep 29, 2020 at 11:49:07AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> tomas wrote:
> 
> > Things become more interesting if the thing coming
> > after #' is a symbol, like in #'car.
> 
> The use case, at least mine, is to denote functions
> so the byte-compiler can check if they are defined.
> Makes development faster and more pleasant...
> 
> Yeah ... what _is_ the origin/reason of this thing,
> deep down? That symbols are not only a value or
> a function but both, and more?
> 
>   symbol-function
>   symbol-value
>   ...

Exactly.

> > Then we all know we are talking about car's
> > symbol-function. This allows the human code readers
> > and the compiler to be smarter about the code.
> 
> Yeah, however what gain is there to mucking with
> that? That cannot be solved, or solved in a worse
> way, with "dedicated symbols", I guess?

Well, #' is just a shorthand for function, just as ' is a
shorthand for quote.

If you do #'car (or, what's the same (function car)), the
compiler can, for example, warn you early that there's no
function named like this (for the symbol car, your Lisp would
be... in a strange state, but you get the idea :)

Plus lots of other optimizations the compiler can do if it
knows that it's the function value you are talking about.

Plus the clarity of your code for your other readers.

All of that isn't necessary for (lambda (...) ...), since
it's lambda's job to make functions. We know that, the
compiler knows that.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: url-retrieve fails on most HTTPS sites

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

> If you do #'car (or, what's the same (function
> car)), the compiler can, for example, warn you
> early that there's no function named like this (for
> the symbol car, your Lisp would be... in a strange
> state, but you get the idea :)

Isn't this just a wierd example of the by contrast
very common use case already mentioned?

> Plus lots of other optimizations the compiler can
> do if it knows that it's the function value you are
> talking about.

Yeah, you have an example of this?

BTW how does _Lisp_ know what is refered to? Value is
default if no #'/`function'? is the value nil if not
set? does it look if the function is set then? no,
right? it uses nil as the value? the value isn't nil
if not set, the value placeholder is void. if the
value is not set, does it look for a function? no,
right, you always have to set that explicitely?
and besides one doesn't want the function to be used
as a value (except for certain very rare/advanced
cases). but how can it look for anything if it
crashes when something isn't set? (when not-set) ;
boom you do this in C instead to get around it?

> Plus the clarity of your code for your other readers.

It makes the code _cooler_ but more clear, I don't
know, really. Perhaps to some.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Sharp--quote [was: url-retrieve fails on most HTTPS sites]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On Tue, Sep 29, 2020 at 12:50:44PM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> tomas wrote:

[...]

> > Plus lots of other optimizations the compiler can
> > do if it knows that it's the function value you are
> > talking about.
> 
> Yeah, you have an example of this?

I think Stefan is in a far better position to answer
that.

One of the things is that, if the compiler knows you're
going for the function definition, it can warn you if
it "knows" this to be unbound in the relevant context.

It might also eliminate check code if it knows that
value to be present (or even use the value directly).

> BTW how does _Lisp_ know what is refered to? [...]

Syntactical context: if you say

  (foo 1 2 3)

it knows it has to look up things in the variable's function
cell, whereas in

  (+ 1 2 foo 3)

it goes and looks up foo's variable's value cell.

> > Plus the clarity of your code for your other readers.
> 
> It makes the code _cooler_ but more clear, I don't
> know, really. Perhaps to some.

As usually, it takes some familiarity. But if I see, in the
middle of something

  (mumble 1 2 #'foo 5)

...then I /know/ "aah, foo is being passed as a function".
Whereas if I see

  (mumble 1 2 'foo 5)

...then I just don't know. It might be used as a function,
as a symbol... whatever.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Sharp--quote [was: url-retrieve fails on most HTTPS sites]

[Stefan Monnier]

>> > Plus lots of other optimizations the compiler can do if it knows
>> > that it's the function value you are talking about.
>> Yeah, you have an example of this?
> I think Stefan is in a far better position to answer that.

AFAIK there is no optimization that applies specifically to #'foo :-(

There's really not much opportunity for optimization there, since all it
says is "use the function found in the `symbol-function` slot *at the time
we actually call it*".  But whatever we know about the content of
`symbol-value` during compilation may not hold anymore by the time the
code is executed.

So the differences w.r.t 'foo are limited to:
- Tell the *human reader* that the intention here is to refer to
  a function of that name.
- Get a warning from the compiler if the function doesn't seem to exist.
- Plus the special case of `cl-flet` and `cl-labels` where the #' is
  needed to refer to the locally-defined function.


        Stefan

Re: Sharp--quote [was: url-retrieve fails on most HTTPS sites]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 209 bytes --]

On Tue, Sep 29, 2020 at 10:56:56AM -0400, Stefan Monnier wrote:

[...

> AFAIK there is no optimization that applies specifically to #'foo :-(

[...]

Thanks. I always enjoy your explanations :-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Sharp--quote [was: url-retrieve fails on most HTTPS sites]

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

> Thanks. I always enjoy your explanations :-)

Should be collected and published by O'Reilly in
a three volume super-edition...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Sharp--quote [was: url-retrieve fails on most HTTPS sites]

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

> AFAIK there is no optimization that applies
> specifically to #'foo :-(
>
> There's really not much opportunity for
> optimization there, since all it says is "use the
> function found in the `symbol-function` slot *at
> the time we actually call it*". But whatever we
> know about the content of `symbol-value` during
> compilation may not hold anymore by the time the
> code is executed.
>
> So the differences w.r.t 'foo are limited to: -
> Tell the *human reader* that the intention here is
> to refer to a function of that name. - Get
> a warning from the compiler if the function doesn't
> seem to exist.

See?

People always think what goes on under the hood is
more advanced and clever than what it is.

Well, I like simplicity anyway :)

Thanks for the summary!

> - Plus the special case of `cl-flet` and
> `cl-labels` where the #' is needed to refer to the
> locally-defined function.

`cl-flet' and `cl-labels' do their own parsing and
look for #' specifically and have it take on
a new meaning?

Reuse of notation with a new meaning within the same
language seems ... not the programmer's way, to be
honest. If #' is an ... yeah, what is it? ... if #'
is [something] that is equivalent to `function',
perhaps one could think of a whole new function, be
it "cl-local" or something.

Or you tend to use so many that it would clutter the
code? Whatever the reason, I'm sure you got it right,
it would just be interesting to hear more from the
supposedly simple underthehoodland :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Sharp--quote [was: url-retrieve fails on most HTTPS sites]

[Emanuel Berg via Users list for the GNU Emacs text editor]

t wrote:

> One of the things is that, if the compiler knows
> you're going for the function definition, it can
> warn you if it "knows" this to be unbound in the
> relevant context.

3rd time? :)

> It might also eliminate check code if it knows that
> value to be present (or even use the value
> directly).

How does this relate to #' or no #'?

>> BTW how does _Lisp_ know what is refered to? [...]
>
> Syntactical context: if you say
>
>   (foo 1 2 3)
>
> it knows it has to look up things in the variable's
> function cell, whereas in
>
>   (+ 1 2 foo 3)

OK!

> As usually, it takes some familiarity. But if
> I see, in the middle of something

No, I've used it (sharp quote) a lot, no less than
413 times! But if I 'grep -v' the three most frequent
settings, i.e. "key", "hook", and "alias", only
47 remains...

>     (mumble 1 2 #'foo 5)
>
> ... then I /know/ "aah, foo is being passed as
>
> a function". Whereas if I see
>
>   (mumble 1 2 'foo 5)
>
> ... then I just don't know. It might be used as
> a function, as a symbol... whatever.

Well, if you give it a better name than "foo" then it
is still pretty clear. But OK, that's true, +1

--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: url-retrieve fails on most HTTPS sites

[황병희]

[i did mark this mail as *important*]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> ' and #' are two different beasts.  If you want to wrap your lambdas
> inside #' be my guest.  But please don't quote them with ' because it
> turns them into "lists which happen to look eerily like functions".
> You can't α-rename lists, you can't byte-compile lists, you can't
> macro-expand lists, you can't detect "bugs" or code smells in lists, ...

Thanks for good information^^^

Sincerely, Gnus fan Byung-Hee 

-- 
^고맙습니다 _白衣從軍_ 감사합니다_^))//

Re: url-retrieve fails on most HTTPS sites

[2QdxY4RzWzUUiLuE]

On 2020-09-29 at 01:41:24 +0200,
Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> Re: url-retrieve fails on most HTTPS sites
> 2QdxY4RzWzUUiLuE wrote:
> 
> > On 2020-09-29 at 01:13:51 +0200,
> > Emanuel Berg via Users list for the GNU Emacs text
> > editor <help-gnu-emacs@gnu.org> wrote:
> >
> >> Nicolas Graner wrote:
> >> 
> >> >   (switch-to-buffer (url-retrieve
> >> > "https://wikipedia.org/" '(lambda (&rest ignore))))
> >> >
> >> > The buffer that shows up is empty.
> >> 
> >> Never heard of `url-retrieve' but I have it and yes,
> >> what "shows up is empty".
> >
> > It works for me.  Sort of.
> >
> > I ran (url-retrieve "https://wikipedia.org/"
> > (lambda (&rest ignore))) in my *scratch* buffer,
> > and watched carefully.
> >
>      (url-retrieve
>       "https://wikipedia.org/"
>       (lambda (&rest ignore)))
>      #<buffer  *http wikipedia.org:443*>
> 
> I search downwards for some sign, signals aren't
> strong enough, perhaps?

At first, I could have sworn that url-retrieve inserted the name of a
second buffer in my *scratch* buffer, but I can't reproduce that now.
It all happened so fast the first time, so maybe it was just my
imagination.

In any case, I ran switch-to-buffer and then pressed the space bar and
the TAB key to display all the buffers whose names began with a space,
and one of those buffers was " *http www.wikipedia.org:443*," and that's
how I found it.

Re: url-retrieve fails on most HTTPS sites

[Colin Baxter]

>>>>> 2QdxY4RzWzUUiLuE  <2QdxY4RzWzUUiLuE@potatochowder.com> writes:

----- Cut -----

    > In any case, I ran switch-to-buffer and then pressed the space bar
    > and the TAB key to display all the buffers whose names began with
    > a space, and one of those buffers was " *http
    > www.wikipedia.org:443*," and that's how I found it.

Yes, that works for me too. Strange. I wonder why the buffer doesn't appear
elsewhere, e.g. when Ibuffer is run?

Best wishes,

Colin Baxter

Re: url-retrieve fails on most HTTPS sites

[2QdxY4RzWzUUiLuE]

On 2020-09-29 at 06:45:54 +0100,
Colin Baxter <m43cap@yandex.com> wrote:

> >>>>> 2QdxY4RzWzUUiLuE  <2QdxY4RzWzUUiLuE@potatochowder.com> writes:
> 
> ----- Cut -----
> 
>     > In any case, I ran switch-to-buffer and then pressed the space bar
>     > and the TAB key to display all the buffers whose names began with
>     > a space, and one of those buffers was " *http
>     > www.wikipedia.org:443*," and that's how I found it.
> 
> Yes, that works for me too. Strange. I wonder why the buffer doesn't appear
> elsewhere, e.g. when Ibuffer is run?

As per the manual¹:

    Buffers that are ephemeral and generally uninteresting to the user
    have names starting with a space, so that the list-buffers and
    buffer-menu commands don’t mention them (but if such a buffer visits
    a file, it is mentioned). A name starting with space also initially
    disables recording undo information; see Undo.

¹ https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Names.html

Re: url-retrieve fails on most HTTPS sites

[Colin Baxter]

>>>>> 2QdxY4RzWzUUiLuE  <2QdxY4RzWzUUiLuE@potatochowder.com> writes:

    > On 2020-09-29 at 06:45:54 +0100,
    > Colin Baxter <m43cap@yandex.com> wrote:

    >> >>>>> 2QdxY4RzWzUUiLuE <2QdxY4RzWzUUiLuE@potatochowder.com>
    >> writes:
    >> 
    >> ----- Cut -----
    >> 
    >> > In any case, I ran switch-to-buffer and then pressed the space
    >> bar > and the TAB key to display all the buffers whose names
    >> began with > a space, and one of those buffers was " *http >
    >> www.wikipedia.org:443*," and that's how I found it.
    >> 
    >> Yes, that works for me too. Strange. I wonder why the buffer
    >> doesn't appear elsewhere, e.g. when Ibuffer is run?

    > As per the manual¹:

    >     Buffers that are ephemeral and generally uninteresting to the
    > user have names starting with a space, so that the list-buffers
    > and buffer-menu commands don’t mention them (but if such a buffer
    > visits a file, it is mentioned). A name starting with space also
    > initially disables recording undo information; see Undo.

    > ¹
    > https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Names.html

Thanks for the information. I really should read the manual.

Best wishes,

HTTPS fails (was: url-retrieve fails on most HTTPS sites)

[Nicolas Graner]

Hi all,

thanks to those who tried to answer my initial question.
However, nobody has addressed the core of the question, which was
neither about the specifics of url-retrieve nor about quoting lambdas :)
Rather, it was about https servers breaking connections.

So, let me try to rephrase it in simpler terms using EWW, the Emacs Web Wrowser.

  (eww "https://theconversation.com/global")
displays a web page rendered as text, as expected.

  (eww "https://wikipedia.org/")
displays briefly "Loading https://wikipedia.org/", then the buffer is
emptied, indicating that the server has closed the connection.

Is it the same for you?
Is it the same with different emacs versions? I am running 26.1 on Debian.

If it's just me, I'll try to find what's wrong with my installation.
If it's more general, I'll file a bug report.

Thanks,
Nicolas

Re: HTTPS fails (was: url-retrieve fails on most HTTPS sites)

[Nicolas Graner]

Please ignore this new thread. Noam Postavsky answered my original
question while I was writing this one :)

Nicolas

Nicolas Graner <nicolas@graner.name> a écrit le 29/09/2020 à 16h53 :
> Hi all,
>
> thanks to those who tried to answer my initial question.
> However, nobody has addressed the core of the question, which was
> neither about the specifics of url-retrieve nor about quoting lambdas :)
> Rather, it was about https servers breaking connections.
>
> So, let me try to rephrase it in simpler terms using EWW, the Emacs Web Wrowser.
[...]

Re: HTTPS fails (was: url-retrieve fails on most HTTPS sites)

[Gregory Heytings via Users list for the GNU Emacs text editor]

Hi Nicolas,

>
> So, let me try to rephrase it in simpler terms using EWW, the Emacs Web 
> Wrowser.
>
> (eww "https://theconversation.com/global") displays a web page rendered 
> as text, as expected.
>
> (eww "https://wikipedia.org/") displays briefly "Loading 
> https://wikipedia.org/", then the buffer is emptied, indicating that the 
> server has closed the connection.
>
> Is it the same for you? Is it the same with different emacs versions? I 
> am running 26.1 on Debian.
>

It works for me on Debian with Emacs 26.1.  It also works with other Emacs 
versions.  So I suspect something is wrong on your side.

Gregory

Re: url-retrieve fails on most HTTPS sites

[Noam Postavsky]

On Mon, 28 Sep 2020 at 16:41, Nicolas Graner <nicolas@graner.name> wrote:

> using 26.1 on Debian, I try to open various web pages with url-retrieve.
> It works with all HTTP and some HTTPS connections, but fails with most
> HTTPS. For instance with Wikipedia:

> Any suggestions as to what could make some sites close the connection,
> or how I could find out more?

I think it's probably Bug#36810; it depends on the exact timing of
network responses, so some servers could trigger it more than others.
If you can't upgrade to 26.3 or later, then

    (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")

in your init file may help.

https://debbugs.gnu.org/36810

Re: url-retrieve fails on most HTTPS sites

[Nicolas Graner]

Noam Postavsky <npostavs@gmail.com> a écrit le 29/09/2020 à 10h47 :
> I think it's probably Bug#36810; it depends on the exact timing of
> network responses, so some servers could trigger it more than others.
> If you can't upgrade to 26.3 or later, then
>
>     (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")
>
> in your init file may help.

Right, it's working. Many thanks!!

Nicolas