HTTPoison vs HTTPotion

I suppose this question is effectively hackney vs. ibrowse but we are at a point in our project where we have to make a choice between the 2 (or maybe there is a 3rd somebody wants to highlight?)

Just wondering if anybody has any constructive reasons as to why they would use one over the other?

2 Likes

I have found Tesla to have a friendlier API

9 Likes

Havenā€™t seen this before - looks pretty cool in that you can switch out and test other adapters.

2 Likes

In my experience most people use Poison.

2 Likes

This is reflected in the Github :star: count but would still be nice to have some opinions on why that is, would be interesting to read a non-biased blog post pitting the 2 against each other in benchmarks and analysing some KPIā€™s relevant to a library/application of this nature.

2 Likes

This performance analysis is interesting, especially if HTTPotion by default isnā€™t running an ā€œoptimizedā€ ibrowse - perhaps the optimization itself (increased session count to 300 and max pipeline count to 1) is irrelevant for anything but benchmarks.

The README does a very bad job of explaining exactly what these results mean to the developer.

I am inclined to go with HTTPoison based on the results of this alone.

3 Likes

HTTPoison (actually, Hackney) comes with secure HTTPS defaults. Last time I checked other HTTP clients, including HTTPotion/iBrowse, will happily let you pass in an HTTPS URL and connect to the server without any verification of the serverā€™s certificate chain or identity (hostname). Basically they obscure the communication to avoid eavesdropping, but they donā€™t protect against MitM attacks unless you explicitly pass in all the right TLS configuration options.

3 Likes

I can attest to this. We have a Ubiquity thing here that mandates HTTPS for its api connection, but it uses a self-signed cert, thus I had to disable HTTPoisons/Hackneys checking. ^.^

1 Like

Thatā€™s probably one of the best reasons I have come across in favour of HTTPoison.

2 Likes

Decided to write a blog post on the security posture of Elixir HTTPS clients. Linked here for future readers of this post:
https://blog.voltone.net/post/7

13 Likes

Tesla looks really nice, with a clean API. :thumbsup:

3 Likes

@voltone Weā€™re now four years further. There are some new OTP versions with updates to the :ssl and related modules, and libraries like mint and HTTP-clients built on top of it (mojito, yet another tesla backend) have been built, how does the HTTP client security landscape look now?

2 Likes

:ssl has improved a bit: it removed support for SSL 3.0, it added TLS 1.3 (still a bit flaky) along with some new ciphers/curves, and better handling of out-of-order certificates coming from the server. But what hasnā€™t changed is the default of verify: :verify_none, both for :ssl.connect/2,3,4 and the :httpc application.

HTTPotion seems to be ā€˜soft deprecatedā€™.

Hackney has had a few issues lately due to :ssl changes. Sometimes it was possible to work around them, until a new version would land, by passing custom ssl options. The major catch there is that any custom ssl options passed to Hackney (and therefore HTTPoison and Tesla) will overwrite the secure defaults. So passing something like ssl: [versions: [:tlsv1_2]] reverts the :verify option back to :verify_none!

Mint attempts to merge custom ssl options with its own secure defaults (which is not trivial to do, since the individual options are inter-dependent). Any libraries that build on Mint should be fine too.

You can consider my ElixirConf EU 2019 talk ā€˜Learn you some :ssl for much securityā€™ to be an updated version of the blog post referenced earlier in this thread. It is already a year old, but still mostly relevant.

7 Likes

Thank you very much for keeping us all informed! :heart:

1 Like

This an underlying problem of the Erlang core, where the :ssl just doesnā€™t do what the name stands for, aka by default doesnā€™t check TLS certificatesā€¦ seriously???

I just donā€™t get why in the Erlang/Elixir community this considerable to be an acceptable thing and not considered as a security vulnerability worth of opening a CVE against itā€¦ I just donā€™t get it!!!t

Why its allowed to continue like this for so many years??? I ask because if it was in one of that programming languages that everyone likes to shame, the CVE would be open immediately.

1 Like

@Exadra37 Sounds like you could make a PR to make a better SSL module (probably starting as a standalone library) and deprecate the old? :slight_smile:

1 Like

I would love to know Erlang to make the merge request to fix the current one.

Itā€™s really necessary to replace it to fix it?

Even if the module needs replacement it should be fixed.

If is a :ssl module it should not ask us to configure it to verify certificates, because that is the main reason the module exists or is the module meant to be for other things and just got a bad name?

As it stands now is like an engineering building an home and asking if we want doors, roof or windows on it.