http/2

http/2

[Lars Ingebrigtsen]

I googled around a bit to see whether anybody's implemented http/2 for
Emacs.  I guess there's no immediate need, really, but eventually web
servers are going to switch to http/2-only, I guess.

Has anybody looked into implementing it?  The spec is horrible and
unwieldy, so I can imagine people just backing away from it in horror,
but...  It's a challenge!

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: http/2

[Stefan Monnier]

> Has anybody looked into implementing it?  The spec is horrible and
> unwieldy, so I can imagine people just backing away from it in horror,
> but...  It's a challenge!

I think in the context of Emacs, "implementing" it, will mean "provide
bindings to a libhttp2 library".  Ideally as a dynlink module.


        Stefan

Re: http/2

[Lars Ingebrigtsen]

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

> I think in the context of Emacs, "implementing" it, will mean "provide
> bindings to a libhttp2 library".  Ideally as a dynlink module.

I think it would be feasible to implement in Emacs Lisp for somebody who
finds binary twiddling in Emacs amusing.  (I can't imagine who.)  Or is
there anything in particular that makes that... unlikely?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

HTTP/2

[Lars Ingebrigtsen]

Emacs will have to implement HTTP/2 one way or another.  Few people have
disabled HTTP 1.x on their servers, but it's going to happen, so I'd
rather see HTTP/2 (and HTTP/3?) support in Emacs sooner rather than
later.

Not, implementing HTTP/2 in Emacs Lisp sounds like a fun and interesting
project, but...  it's probably too much fun?  So using an existing
well-supported HTTP/2 library (preferably one that already uses GnuTLS,
I guess?) is probably the way forward.

Has anybody looked at this?  I have done absolutely no research here --
are there a bunch of suitable HTTP/2 libraries we could consider?  Or
even one?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: HTTP/2

[Robert Pluim]

>>>>> On Fri, 02 Oct 2020 04:55:58 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Emacs will have to implement HTTP/2 one way or another.  Few people have
    Lars> disabled HTTP 1.x on their servers, but it's going to happen, so I'd
    Lars> rather see HTTP/2 (and HTTP/3?) support in Emacs sooner rather than
    Lars> later.

    Lars> Not, implementing HTTP/2 in Emacs Lisp sounds like a fun and interesting
    Lars> project, but...  it's probably too much fun?  So using an existing
    Lars> well-supported HTTP/2 library (preferably one that already uses GnuTLS,
    Lars> I guess?) is probably the way forward.

libcurl uses nghttp2 for its HTTP/2 support, and it can use GnuTLS, so
we can steal^winspire our implementation from that.

    Lars> Has anybody looked at this?  I have done absolutely no research here --
    Lars> are there a bunch of suitable HTTP/2 libraries we could consider?  Or
    Lars> even one?

Based on my whole 5 mins of research, thereʼs at least one, and if
itʼs good enough for curl I guess itʼs good enough for us.

BTW, nghttp2 is MIT-licensed, would that be an issue? wget2, which is
GLPv3-or-later can use nghttp2 as well.

Robert
-- 

Re: HTTP/2

[Helmut Eller]

On Fri, Oct 02 2020, Robert Pluim wrote:

>>>>>> On Fri, 02 Oct 2020 04:55:58 +0200, Lars Ingebrigtsen
> <larsi@gnus.org> said:
>
>     Lars> Emacs will have to implement HTTP/2 one way or another.  Few
>     Lars> people have
>     Lars> disabled HTTP 1.x on their servers, but it's going to happen, so I'd
>     Lars> rather see HTTP/2 (and HTTP/3?) support in Emacs sooner rather than
>     Lars> later.
>
>     Lars> Not, implementing HTTP/2 in Emacs Lisp sounds like a fun and
>     Lars> interesting
>     Lars> project, but...  it's probably too much fun?  So using an existing
>     Lars> well-supported HTTP/2 library (preferably one that already
>     Lars> uses GnuTLS,
>     Lars> I guess?) is probably the way forward.
>
> libcurl uses nghttp2 for its HTTP/2 support, and it can use GnuTLS, so
> we can steal^winspire our implementation from that.

I'd rather see bindings for libcurl directly.  In particular something
that integrates libcurl's "multi handles" with Emacs' event loop.

Helmut

Re: HTTP/2

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Date: Sun, 04 Oct 2020 19:07:57 +0200
> 
> > libcurl uses nghttp2 for its HTTP/2 support, and it can use GnuTLS, so
> > we can steal^winspire our implementation from that.
> 
> I'd rather see bindings for libcurl directly.

Why?

Re: HTTP/2

[Helmut Eller]

On Sun, Oct 04 2020, Eli Zaretskii wrote:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Date: Sun, 04 Oct 2020 19:07:57 +0200
>> 
>> > libcurl uses nghttp2 for its HTTP/2 support, and it can use GnuTLS, so
>> > we can steal^winspire our implementation from that.
>> 
>> I'd rather see bindings for libcurl directly.
>
> Why?

Because libcurl supports many other protocols, e.g. SCP.  Maybe nghttp2
would be useful, if somebody wanted to implement a HTTP/2 server.

Helmut

Re: HTTP/2

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 04 Oct 2020 19:57:19 +0200
> 
> >> I'd rather see bindings for libcurl directly.
> >
> > Why?
> 
> Because libcurl supports many other protocols, e.g. SCP.

If someone needs those other protocols, they can always develop an
Emacs module which used libcurl.  That is not a reason good enough to
have yet another dependency library for building Emacs.  For that, we
need to carefully consider which protocols we really need and what
for, and only add another library if we really use a large fraction of
its capabilities.  IMO, at least.