HTTP/2 Support

[wohali]

@janl:

• cowboy
• needs fabric / couch_httpd refactor
• would obviate the need for WebSockets
  I think this is an obvious first next step. Our HTTP Layer needs work, our existing HTTP server library is not getting HTTP2 support, it’s time to attack this head-first. I’m imagining a Cowboy-based HTTP layer that calls into a unified internals layer and everything will be rose-golden. HTTP2 support for Cowboy is still in progress. Maybe we can help them along, or we focus on the internals refactor first and drop Cowboy in later (not sure how feasible this approach is, but we’ll figure this out.

In my head, we focus on this and call the result 3.0 in 6-12 months. That doesn’t mean we only do this, but this will be the focus (more on this later).

There are a few fun considerations, mainly of the “avoid Python 2/3-chasm”-type.

• Do we re-implement the 2.0 API with all its idiosyncrasies, or do we take the opportunity to clean things up while we are at it?
• If yes, how and how long do we support the then old API?
• Do we manage this via different ports?
• If yes, how can this me made to work for hosting services like Cloudant? Etc. etc.

For the HTTP API upgrades, we should look at this as a step in refactoring the logic quite a bit and working for clean interfaces internally. If we include that as part of the work then having HTTP/HTTP2/WebSockets/Whatevers interfaces available would become much easier. This then enables follow on features like replication over WebSockets or even easier integration work as Koco suggests. I also agree that this is probably our highest priority major feature.

[janl]

since all this went down, we kinda sorta decided we don’t want to go down the cowboy route. Alternatives are TBD.

Since haproxy has H2 support now, and since it is useful to run it even in front of a single instance CouchDB, we have some time to get to this.

[cluxter]

This then enables follow on features like replication over WebSockets

Huge +1 for support of replication through WebSockets since it saves a lot of overheads. Also would be awesome to be able to use WebSockets to connect to CouchDB at some point.

EDIT: from what I understood, WebSockets over SSL (WSS) create a secure channel between the client and the server, which avoids the need for authenticating for each request.

[yhilem]

IBM Cloudant supports HTTP/2 : "HTTP2 support for higher performance connections to IBM Cloudant" (https://github.com/IBM/cloudant-java-sdk)

[wohali]

@yhilem Yup, and they also use a proxy in front of CouchDB. This is recommended standard practice. Terminate your HTTP/2 (or QUIC!) SSL connection at e.g. haproxy, then haproxy forwards it on to CouchDB.

[rupamking1]

@wohali please tell me when you want to implement http2 in CouchDB. I watched that you see is created on 2018. Please tell me when you you want to implement it on CouchDB.

[wohali]

I'm just a project management committee member here, not an implementer on this type of feature.

Implementing this is a lot of work. Pull requests are welcome!

[kocolosk]

I think Jan's original notes are still spot-on a few years later, with "Cowboy" as a proxy for "some modern Erlang / Elixir HTTP server" and "2.0 / 3.0" replaced with "3.0 / 4.0".

If we decide to move forward on the versioned API topic currently under discussion on the ML I would advocate for the 4.0 API to pull in a new HTTP server that would deliver HTTP2 support amongst other goodies.

[TheRook]

There is an erlang HTTP/2 server that supports many of the exciting HTTP/2 features like server-push, which can be used for pub/sub and event notification:
https://github.com/tatsuhiro-t/lucid

It is MIT licensed, which is Apache compatible and pure erlang. "Do one thing and do it well" Let lucid make the best http/2 erlang server, and then Couch can benefit. This would be native erlang events triggered by HTTP/2 and distributed to any compatible client - a javascript client running PouchDB would be made both made more efficient. HTTP/2 fits the couchDB ethos so much better than any alternative right now.

[wohali]

This project was started primarily for the author to learn Erlang/OTP.

...and has not been updated since 2015. This would not be a good fit for CouchDB long term.

[TheRook]

Cowboy has wide adoption and support http/2 streams: https://github.com/ninenines/cowboy

…

On Mon, Dec 12, 2022 at 6:25 PM Joan Touzet ***@***.***> wrote: This project was started primarily for the author to learn Erlang/OTP. ...and has not been updated since 2015. This would not be a good fit for CouchDB long term. — Reply to this email directly, view it on GitHub <#1497 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7MNZYOFKWFNB5V6VHH6LWM7NB7ANCNFSM4FOIW6AA> . You are receiving this because you commented.Message ID: ***@***.***>

[pertsevds]

How about https://github.com/mtrudel/bandit ?

[nickva]

If it's integrates and works well with Erlang. To me, cowboy so far seems the most promising and been around the longest. Even started to gain some experimental HTTP3 support lately, as well.