ninenines / gun

HTTP/1.1, HTTP/2, Websocket client (and more) for Erlang/OTP.
ISC License
891 stars 232 forks source link

Remove client_preferred_next_protocols #324

Closed zuiderkwast closed 3 months ago

zuiderkwast commented 6 months ago

Fixes #323

belowEV commented 3 months ago

Hej @zuiderkwast, I would like to ask if you have some idea when this change could be merged? It would be great for us to have this correction in both cowboy and gun. Thanks in advance!

zuiderkwast commented 3 months ago

Hej @belowEV. It's hard to know. I have some open PRs, the oldest one from 2021, still not merged.

Ping @essen. A release would be nice. In the mean time, getting stuff merged to master would be nice.

essen commented 3 months ago

I will have to produce a small Gun release so I will include this. For the rest, HTTP/3 takes priority, but I am almost done and the merge to master should happen this month.

zuiderkwast commented 3 months ago

@essen Sorry to say, but HTTP/3 is of no interest to us currently. The 3GPP standards we have to follow mandate HTTP/2 for the REST APIs mobile network nodes use to communicate with each other. The added dependencies to quicer is rather a problem to us, as we will have to make sure it is safe, even though we'll not be using it. A possibility to compile without quicer would be appreciated.

essen commented 3 months ago

There are no plans to make quicer a dependency, it will always be behind a compilation flag at most. Furthermore the HTTP/3 code in Gun will only work within the context of the Cowboy test suite, initially. So Gun will not depend at all on quicer and it will not be possible to use HTTP/3 with Gun for a while. The changes to the common modules are also very limited so there isn't much to worry about. gun_http3 and gun_quicer can always be deleted if necessary.

Anyway the small release I am preparing relates to HTTP/2. I can't say much more than that at this point.

essen commented 3 months ago

@essen Sorry to say, but HTTP/3 is of no interest to us currently.

For the record, maybe I'm wrong, but I do not think I am getting paid by Ericsson currently (or really, ever). I appreciate the patches and get to them when I have time, but I have to prioritize. Both the small release(s) I am producing now, and the (admittedly, very long) HTTP/3 work, are a priority for RabbitMQ, which pays my bills. Most of my time before the HTTP/3 work was also spent on fixing legacy problems in RabbitMQ, which is much better now and I can do other things. So response times will likely improve in the future, but there's always going to be priorities and they will not necessarily match with Ericsson.

The 3GPP standards we have to follow mandate HTTP/2

It's a bit of a shame, because HTTP/2 has received a lot of push back and there's talks of making HTTP/3 and a subset of QUIC work over TCP, to phase HTTP/2 out.

essen commented 3 months ago

Merged, thanks!

zuiderkwast commented 3 months ago

HTTP/3 will most likely be in those standards sooner or later. It's probably just a matter of time. In the end, we'll probably be grateful to the work you're doing on HTTP/3.

I understand you have to prioritize. I'm not in a position where I can sponsor anyone economically though.

essen commented 3 months ago

No worries. Once HTTP/3 is merged new releases can happen more frequently as it will stay experimental for a while. The lack of pure Erlang / OTP built-in QUIC implementation means it will not be generally available for years. The merge will ensure work can happen concurrently without generating huge deltas which have been causing me some troubles in the branch.

zuiderkwast commented 3 months ago

Regarding OTP built-in QUIC implementation: If QUIC is added in telecom standards, which is likely to happen, then I guess it can be included in OTP too at some point. That's just my guess.

essen commented 3 months ago

Yes. Working on an Erlang implementation with the goal of inclusion in OTP is something I might be allowed to do in a few months (or more than a few). But first I have to get a PoC ready for MQTT over HTTP/3 Websocket and then expand upon that.