From zuse@REDACTED  Fri Oct  3 20:06:00 2003
From: zuse@REDACTED (Riccardo Mottola)
Date: Fri, 03 Oct 2003 20:06:00 +0200
Subject: Cannot compile on OpenBSD R9C
Message-ID: <BBA38727.92DB%zuse@libero.it>

Hello,

I cannot compile R9C-0 on OpenBSD 3.3 for sparc. R9B neither.

I searched the list around and found that the OpenBSD problem comes and goes
from time to time... The package included is till a very old one and is not
enough to run the Wings3D modeler for example.

Is this the correct list where to ask? or better erlang-questions? The
"problem" I have is not SSL but also a VM problem.

Now, I searched archives better... and I found a mail that hitend two
patched.

I modified the memsup.c file and also the Makefile.


now the build completes. I think those patches should be merged in the main
tree and also the OpenBSD manintainers should be thereafter convinced of
upgrading their package! v47 is a bit old.

make install gives a lot of warnings of obsolete stuff, but comes to and end
and "erl" exectues.

Now I build esdl and hope it will work :-)

-Ric



From erik.ej.reitsma@REDACTED  Mon Oct 20 14:05:56 2003
From: erik.ej.reitsma@REDACTED (Erik Reitsma EJ (RY/ETM))
Date: Mon, 20 Oct 2003 14:05:56 +0200
Subject: Bug in http client code (httpc_handler)
Message-ID: <440A2703A54A8F4FB2AC2AE34F27129D0549590E@ESEALNT889.al.sw.ericsson.se>

Hi,

I have found what seems to me like a bug in httpc_handler in inets-3.0.7 (and also in inets-3.0.6). The problem is, that in some situation the body of an HTTP POST is sent twice.

When I do an HTTP POST to a .NET server, the .NET server responds with a 100-continue, whether I ask for it or not. In the documentation of httpc_handler:status_continue/2 it says, that this should be ignored if the request has already been completed. In my case, this is already completed, because the POST body is sent immediately if I do not specify that I wish to expect the 100-continue. Therefore the body gets sent twice: once at the initial request, and again when the .NET server sends the status code 100.

I have replaced the implementation of httpc_handler:status_continue/2 with the following code:

status_continue(Req,Session) ->
    Headers = Req#request.headers,
    Method = Req#request.method,
    if
	Method==post;Method==put ->
	    case Headers#req_headers.expect of
		"100-continue" ->
		    %% only in this case we have not yet send the body
		    {_,Body}=Req#request.content,
		    http_lib:send(Session#tcp_session.scheme,Session#tcp_session.socket,Body),
		    next_response_with_request(Req,Session);
		_ ->
		    %% in other cases the status code should be ignored
		    next_response_with_request(Req,Session)
	    end;
	true ->
	    %% in other cases the status code should be ignored
	    next_response_with_request(Req,Session)
    end.

This seems to me to be a more correct implementation of the comments in the original source of httpc_handler. It solves the problem I had and should not break anything.
For inets-3.0.6, #tcp_session should be replaced by #session.

*Erik.



From alexey@REDACTED  Wed Oct 29 15:03:49 2003
From: alexey@REDACTED (Alexey Shchepin)
Date: Wed, 29 Oct 2003 16:03:49 +0200
Subject: Bug in R9C SSL
Message-ID: <87ad7k16pm.fsf@office.sevcom.net>

Hi!

There is a bug in ssl_broker.erl: when ssl:recv/3 called with finite
timeout value, and it reach this timeout, socket switches to closed state.

Patch that fixes this problem:

--- ssl_broker.erl.orig Wed Oct 29 15:31:47 2003
+++ ssl_broker.erl      Wed Oct 29 15:32:50 2003
@@ -330,6 +330,8 @@
            case gen_tcp:recv(St#st.proxysock, Length, Timeout) of
                {ok, Data} ->
                    {reply, {ok, Data}, St};
+               {error, timeout} ->
+                   {reply, {error, timeout}, St};
                {error, Reason} ->
                    {reply, {error, Reason}, St#st{status = closing}}
            end