-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explicit HTTP persistent connection #301
Comments
Regardless of adapter backend (stateless or not) it would require passing some kind of client identifier, which should be configurable. Consider this two client:
Now, in a typical phoenix web app:
In case of Do you have any ideas how could the be solved on the interface side? |
We may store connection ref (state) in # adapter should build blank state
client = Tesla.client([BaseUrl, url}, {PersistentAdapter, option_a: foo}]
# adapter should pass existing ref or new state so that Tesla.Client in the result result has the ref
{:ok, %{body: body, client: client}} = Tesla.get(client, path1)
# adapter should reuse existing ref in Tesla.Client
{:ok, %{body: body, client: client}} = Tesla.get(client, path2) We may introduce it as |
This would break the user-friendly API, it's also not trivial to use in the (not only) webapp context as you don't have a good place to store |
So I am confused... are you saying that developer convenience is more important that security in the library or that security must be delegated to the adapters? |
Background
httpc and hackney implements HTTP persistent connection by themselves - not requiring passing any reference to existing connection, but using connection by host.
This results in strange behavior, such as not honoring other options (e.g. SSL), which is very bad for security.
Related:
Please note that mint is process-less, so it can not provide HTTP persistent connection unless someone (e.g. Tesla) provides pool management. Once we have connection pool logic in tesla, we may update all adapters to explicitly use the reference, not relying on behind-the-scene behavior of underlying libraries.
Why not just delegating to adapter/underlying library
From @teamon 's comment
I agree that "keeping connection a live " is a low-level operation and not a main job of tesla. However, at the same time, Tesla SHOULD not hide HTTP behavior. For example, two different tesla client should not share any connection - but they do.
Example
This is very bad, when you need to build client and ssl options based on user input (e.g. say, your service takes webhook URL from user).
There are several workrounds
However, still, by default Tesla and httpc / hackney is insecure 😞
The text was updated successfully, but these errors were encountered: