{packet, http} with gen_tcp:connect/2 problem

[Michael Truog]

When {active, false} and {packet, http} are used with gen_tcp:connect/2
there is a difference between what dialyzer (in R13B02-1 or R13B01)
expects and what happens in reality.  Based on the code here:
erts/emulator/beam/erl_bif_port.c on line 1230 in R13B02-1

It makes sense that you can get a response {ok, {http_error, _}} when
calling "case gen_tcp:recv(Socket, 0, Timeout) of" and this is the
result dialyzer expects.  However, in reality I get {error, {http_error,
_}} and need to make sure my code is {_, {http_error, _}} to avoid the
problem.  I am not sure what is changing the output of
erlang:decode_packet/3.

- Michael

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[Sverker Eriksson]

Hi,

gen_tcp:recv has been returning {error,{http_error,_}} instead of
{ok,{...}} since the beginning (when it was an undocumented feature used
by some privileged applications), so I don't think we can change that
without breaking backwards compatibility. I guess we have to introduce
this "exception to the rule" in both the documentation and dialyzer.

About the code:
gen_tcp with {packet,http} does not use erlang:decode_packet or any of
the http related code in erl_bif_port.c.
The common code used by both gen_tcp and decode_packet is in
beam/packet_parser.c.
The terms returned from the socket are then contructed by code in
emulator/drivers/common/inet_drv.c.


/Sverker, Erlang/OTP Ericsson


Michael Truog wrote:

> When {active, false} and {packet, http} are used with gen_tcp:connect/2
> there is a difference between what dialyzer (in R13B02-1 or R13B01)
> expects and what happens in reality.  Based on the code here:
> erts/emulator/beam/erl_bif_port.c on line 1230 in R13B02-1
>
> It makes sense that you can get a response {ok, {http_error, _}} when
> calling "case gen_tcp:recv(Socket, 0, Timeout) of" and this is the
> result dialyzer expects.  However, in reality I get {error, {http_error,
> _}} and need to make sure my code is {_, {http_error, _}} to avoid the
> problem.  I am not sure what is changing the output of
> erlang:decode_packet/3.
>
> - Michael
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>
>  

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[Kostis Sagonas-2]

Sverker Eriksson wrote:
> Hi,
>
> gen_tcp:recv has been returning {error,{http_error,_}} instead of
> {ok,{...}} since the beginning (when it was an undocumented feature used
> by some privileged applications), so I don't think we can change that
> without breaking backwards compatibility. I guess we have to introduce
> this "exception to the rule" in both the documentation and dialyzer.

I do not really see any problem as far as backwards compatibility for
the masses is concerned.  Even today, the documented behaviour of
gen_tcp (http://www.erlang.org/doc/man/gen_tcp.html) reads:

   recv(Socket, Length) -> {ok, Packet} | {error, Reason}
   recv(Socket, Length, Timeout) -> {ok, Packet} | {error, Reason}

   Types:
    Socket = socket()
    Length = int()
    Packet = [char()] | binary()
    Timeout = int() | infinity
    Reason = closed | posix()

where posix() is an atom.

Programs that explicitly match on {error, {http_error, _}} rely on
something undocumented and they should know better that this could
change at any time.

Moreover, dialyzer exists and automatically identifies all these places
in the code and is there to help users in changing them.

What's the problem in making the right decision here?

Erlang has too many inconsistent return values in its key functions.
Does it need another one?

Kostis

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[Sverker Eriksson]

Kostis Sagonas wrote:

> :
>
> Programs that explicitly match on {error, {http_error, _}} rely on
> something undocumented and they should know better that this could
> change at any time.
>
> Moreover, dialyzer exists and automatically identifies all these
> places in the code and is there to help users in changing them.
>
> What's the problem in making the right decision here?
>

Fear of breaking "established" applications such as Yaws and Mochiweb, I
guess...

> Erlang has too many inconsistent return values in its key functions.
> Does it need another one?
>
No, maybe we should muster the courage to do the right thing then...

/Sverker, Erlang/OTP


________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org