GoAhead WebServer in RTEMS

[Steven Johnson]

Joel Sherrill wrote:
> Chris Johns wrote:
>   
>> Eric Valette wrote:
>>   
>>     
>>> It is indeed. It wasn't at the time of submission (about 5 years ago
>>> already). If I had to select one now, I would choose the one by the guy
>>> that did GoHead dev and that is still compatible with goahed : appweb
>>> <www.appweb.org>.
>>>
>>>     
>>>       
>> Do you mean http://www.appwebserver.org/ ?
>>   
>>     
>
> The license for that is pure GPL so isn't good for RTEMS.  If the 
> GoAhead webserver is
> indeed obsolete, then we need to identify another candidate and port it.
>   
Hello,

Over the weekend we decided to not use the go-ahead server for various 
reasons.

I am in the process of porting shttpd (simple httpd) to rtems (it is a 
candidate for a go-ahead replacement in RTEMS official tree). See:
shttpd.sourceforge.net/

It is very very simple.  It is small (around 20K for me compiled on 
MPC862 power-pc). 

It seems to have all of the features (different implementations/API 
though) of the go-ahead one, with the exception of:
1. server side includes
2. go-aheads non-standard ASP implementation
(neither of which I use). 

The author doesn't seem very interested in server side includes or ASP 
like interfaces, but as with any open-source project I am sure he would 
probably put the code in if it was contributed.

It uses less memory.  It still allows any URI to be generated by C/C++ 
code, or retrieved from the file system.  It handles binary uploads much 
much easier, which is one of the main reasons I have dropped go-ahead.

There are examples of using the server where multiple threads are 
spawned to handle multiple in-coming connections to distribute load.  I 
don't need to do this, but it should be possible to do it easily on 
RTEMS, following the example.

The port consisted of:

1. Disabling the SSL Code, because it tries to dynamically load the SSL 
Library which doesn't really fit with the RTEMS system.
2. Removing the inclusion of one header that is #included for the Linux 
port, but that RTEMS doesnt have (at least my build doesn't have it)
3. Implementing macros for its used of a single mutex used by the server.

I have not yet tested it, but once I do and fixed any bugs I have 
introduced, I will be submitting my patches to main source tree.  I will 
also send the patches to this list, in case RTEMS wants its own copy.

The file is a single shttpd.c and shttpd.h file.

It is licensed under the BSD license, so is completely compatible with 
the RTEMS license.

Also, if you look at it, use the CVS version.  The last official version 
has a slightly different API to CVS, and the last official doesnt 
support large binary uploads.  My porting work is on the CVS version.

2 changes I intend to make the security API enhanced are:
1. allow passwords and user names for pages to be set programmatically, 
rather than requiring a password file.
2. allow a security check function to be installed by an application so 
that custom security checking can be added by the user.


Steven J