You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
last.fm uses the XMLRPC server at ws.audioscrobbler.com. Using the example Python code for accessing this server works fine, but using the equivalent for Erlang didn't work. Studying the output with Wireshark, I noticed that Erlang wasn't outputting a Host header, and started digging into the XMLRPC code. Hacking a Host header manually into the POST fixed the basic bug, but other issues cropped up (the request comes back as "HTTP/1.0 200 OK" not HTTP/1.1), and they all appeared to come back to being a result of manually building/parsing the HTTP request as opposed to using the inets http client, which would seems the sensible option to me!
Problem with rewriting the xmlrpc module like that is that call/3 and call/5 wouldn't work as inets won't let you specify the socket to use AFAIK, and I can't seem to figure out how to set KeepAlive with that, but it still seems like a sensible option.
Example code used for testing:
-module(lastfm).
-export([start/0]).
start() ->
io:format("~p~n", [artist()]).
artist() ->
case xmlrpc:call("ws.audioscrobbler.com", 80, "/2.0/", {call, artist.search, [{struct,[{artist,"blah"}]}]}, false,
10000) of
{error, Reason} ->
{error, Reason};
{ok, Result} ->
Result
end.
The text was updated successfully, but these errors were encountered:
Thank you for this report. I will investigate that issue soon. But the time I'm able to invest into that project is very limited right now. In the meantime you are welcome to submit a patch for that problem.
last.fm uses the XMLRPC server at ws.audioscrobbler.com. Using the example Python code for accessing this server works fine, but using the equivalent for Erlang didn't work. Studying the output with Wireshark, I noticed that Erlang wasn't outputting a Host header, and started digging into the XMLRPC code. Hacking a Host header manually into the POST fixed the basic bug, but other issues cropped up (the request comes back as "HTTP/1.0 200 OK" not HTTP/1.1), and they all appeared to come back to being a result of manually building/parsing the HTTP request as opposed to using the inets http client, which would seems the sensible option to me!
Problem with rewriting the xmlrpc module like that is that call/3 and call/5 wouldn't work as inets won't let you specify the socket to use AFAIK, and I can't seem to figure out how to set KeepAlive with that, but it still seems like a sensible option.
Example code used for testing:
The text was updated successfully, but these errors were encountered: