httpc crashing on particular urls

--===============1014501854250938580==
Content-Type: multipart/alternative; boundary=001a11c002b01677780520e9847f

--001a11c002b01677780520e9847f
Content-Type: text/plain; charset=UTF-8

Hello everybody, it is my first appearance on this mailing list so feel
free to remind me of all the rules I possibly break...

I noticed that in one specific case the inets:httpc request function fails
to return a meaningful error and silently crashes instead. This seems to
happen when the provided URL scheme is not http or https. I am just an
Erlang beginner so I don't expect to be able to provide a good patch, but I
have written up a mockup patch that does solve the issue, although the
error message it produces is very likely not in line with the conventions
used and the code itself is ugly and based only on guesswork from the
surrouding code without any real understanding of what I am doing.

Anyway to reproduce the bug you might try to execute the following request
on httpc: httpc:request(get, {"broken://erlang.org:80", []}, [],
[{sync,false}, {stream, self}, {receiver,fun(X)-> io:format("~p",[X])end}]).

Instead of an error I get {ok, #Ref} and in the background a httpc crash.
The same happens on sync requests as well and the erl shell hangs.

The mock fix that I wrote is available here:
https://github.com/lantti/otp/commit/8872f1ca2986757a670f386eba022481f126febc

The main points there to notice are that the function socket_type() fails
with a missing clause when an unrecognized URL scheme is introduced and
that we are inside the httpc:init where failing is not allowed. So I fixed
that by returning an error tuple instead and pattern matching against that
tuple at the calling side.

Maybe somebody here would like to take the time to actually write that fix
properly.

Thank you,

Antti Siponen

--001a11c002b01677780520e9847f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hello everybody, it is my first appearance =
on this mailing list so feel free to remind me of all the rules I possibly =
break...<br><br>I noticed that in one specific case the inets:httpc request=
 function fails to return a meaningful error and silently crashes instead. =
This seems to happen when the provided URL scheme is not http or https. I a=
m just an Erlang beginner so I don&#39;t expect to be able to provide a goo=
d patch, but I have written up a mockup patch that does solve the issue, al=
though the error message it produces is very likely not in line with the co=
nventions used and the code itself is ugly and based only on guesswork from=
 the surrouding code without any real understanding of what I am doing.<br>=
<br>Anyway to reproduce the bug you might try to execute the following requ=
est on httpc: httpc:request(get, {&quot;broken://<a href=3D"http://erlang.o=
rg:80">erlang.org:80</a>&quot;, []}, [], [{sync,false}, {stream, self}, {re=
ceiver,fun(X)-&gt; io:format(&quot;~p&quot;,[X])end}]).<br><br>Instead of a=
n error I get {ok, #Ref} and in the background a httpc crash. The same happ=
ens on sync requests as well and the erl shell hangs.<br><br>The mock fix t=
hat I wrote is available here:<br><a href=3D"https://github.com/lantti/otp/=
commit/8872f1ca2986757a670f386eba022481f126febc">https://github.com/lantti/=
otp/commit/8872f1ca2986757a670f386eba022481f126febc</a><br><br>The main poi=
nts there to notice are that the function socket_type() fails with a missin=
g clause when an unrecognized URL scheme is introduced and that we are insi=
de the httpc:init where failing is not allowed. So I fixed that by returnin=
g an error tuple instead and pattern matching against that tuple at the cal=
ling side.<br><br></div>Maybe somebody here would like to take the time to =
actually write that fix properly.<br><br></div>Thank you,<br><br></div>Antt=
i Siponen<br></div>

--001a11c002b01677780520e9847f--

--===============1014501854250938580==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches

--===============1014501854250938580==--