Inets HTTP client stability

[Heinrich Venter]

>Joe Armstrong (AL/EAB) wrote:
>> Processing HTTP is *extremely* easy - .....

Klacke wrote
>I'd like to state the opposite - Processing HTTP is very hard since
HTTP is a complex protocol.

I suspect both statements are true.  If you know the behavior of the
clients you will be talking to, it should be very easy to just do
something sockety and have it done with.
If on the other hand you don't know the nature of the clients, a lot of
weird and wonderful things can happen (like chunking, not quite
conformant packets etc)

I have decided to go with inets httpd because:
- I don't know the nature of the clients, except that in general they
will not be browsers, so I expect wierdnes
- In future I might have to support SOAP.  The only (mostly) working
SAOP interface has an inets:httpd module already written.

For the outgoing client:
- My demands on the client will be simple GET/POST requests
- The responses on the requests in general will be simple

It might be worth while to do a simple sockety thing for the client
instead of using inets or ibrowse. But since I already have inets as
part of the picture, I might as well use what it offers.

Just to give a clearer idea of what I am trying to do:
I am writing a gateway application that will expose an http interface to
some of our internal systems.  It will accept incoming messages as
GET/POST and pass the data to our application.  The applicatino may
independantly generate messages that need to be delivered to a host that
exposes a similar http interface.
In other words, the external in and out interfaces are http, while the
internal interfaces will be Erlang messages among others.
There is a need for some internal queueing in the gateway to prevent
flooding.

-]-[einrich