Allow both hackney 1.x and 4.x#170
Conversation
Let's allow both old and new hackney versions in order to make the transition easier for downstream projects. Closes lau#155.
|
@lau this is a good fix. Any thoughts? |
|
@lau hi, i hope you're doing great. this pr contains important changes to mitigate the vulnerability with hackney, i hope you can speed up the resolution process. |
|
Hi, @lau Any chance to merge it and bump a new version for tzdata ? |
| # Hackney 4.x returns the body as a binary in the result from :hackney.get | ||
| {:ok, result} | ||
| end | ||
| defp get_body(client_ref) do |
There was a problem hiding this comment.
I think it's best to drop support for Hackney 1.x considering hackney 1.x is vulnerable and this major version won't be maintained anymore.
There was a problem hiding this comment.
Longer term, absolutely. My goal with this change is to make it easier for a project with a complex dependency tree to move towards Hackney 4.x. If one dependency depends on Hackney 1.x and another depends on 4.x, the upgrade is blocked, but if tzdata allows both versions, then progress towards Hackney 4.x can be made step by step.
| end | ||
| defp get_body(client_ref) do | ||
| # Hackney 1.x returns a client_ref that we can fetch the body from | ||
| :hackney.body(client_ref) |
There was a problem hiding this comment.
should there be a deprecation warning here?
|
can |
That is a good point. I think it makes sense to declare it as optional. I wasn't sure whether to include it in this pull request or as a separate change, but maybe that's worth doing. |
|
+1
Also see #155 |
9 participants
Let's allow both old and new hackney versions in order to make the transition easier for downstream projects.
Closes #155.
This is an alternative to #168.