-
Notifications
You must be signed in to change notification settings - Fork 10
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
Use lhttpc instead of httpc #13
base: master
Are you sure you want to change the base?
Conversation
@zp-sd as said on slack I would use hackney instead of lhttpc. I'm the maintainer of hackney so any updated needed would be easier. Can you make the change? one question is if checking if setting the option to a profile using |
@zp-sd if you have a simple way to test we can eventually try the second method. Let me know :) |
|
||
Req = {Url, Headers, "text/xml; charset=\"utf-8\"", Msg}, | ||
|
||
case httpc:request(post, Req, [], Options) of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Provided that the caller passes a profile not used by concurrent requests, would avoiding to place the httpc process in the supervisor solve the issue? Requires somehow determining profile to use in httpc call.
Refs:
Snippet:
httpc_request(Method, Request, HTTPOptions, Options, Profile) ->
{ok, Pid} = inets:start(httpc, [{profile, Profile}], stand_alone),
Response = httpc:request(Method, Request, HTTPOptions, Options, Pid),
ok = gen_server:stop(Pid, normal, infinity),
Response.
Past usages that may be referred to:
test path on amplifi router
* Aviod a crash in http_transport:close/2, happening when setting socket_opts in httpc in OTP 20.1. The fix for the bug is included in OTP 21 - https://bugs.erlang.org/browse/ERL-605. * Avoid crash report when httpc_handler_sup is killing its children after unsuccessful httpc:request/1 function call. It happens in some router softwares, with miniupnpd daemon installed, but UPnP/NAT-PMP functionality turned off. Then, during natupnp_v1/natupnp_v2 discovery, location is returned, but is it not responding (hence httpc:request/1 crash).
* Aviod a crash in http_transport:close/2, happening when setting socket_opts in httpc in OTP 20.1. The fix for the bug is included in OTP 21 - https://bugs.erlang.org/browse/ERL-605. * Avoid crash report when httpc_handler_sup is killing its children after unsuccessful httpc:request/1 function call. It happens in some router softwares, with miniupnpd daemon installed, but UPnP/NAT-PMP functionality turned off. Then, during natupnp_v1/natupnp_v2 discovery, location is returned, but is it not responding (hence httpc:request/1 crash).
Given that we're on OTP 22/23 these days, the PR seems moot? |
The fix for the bug is included in OTP 21 - https://bugs.erlang.org/browse/ERL-605.
It happens in some router softwares, with miniupnpd daemon installed, but UPnP/NAT-PMP functionality turned off.
Then, during natupnp_v1/natupnp_v2 discovery, location is returned, but is it not responding (hence httpc:request/1 crash).