Created for httap.org by YG - 2017/04/01
Version : 2020/04/26
This is a minimally HTTP1.1-compliant, tiny server that runs inside another host program. This program can then communicate with other ressources and/or be queried or controlled. Static pages are served as usual while the API can be implemented with the HTTaP protocol.
The host program can perform any operation it likes but it must poll/wake up/call the server several times per second. If the host program stops and goes idle, the server can be set to the "blocking" mode where the program is woken up by external HTTP requests.
The server implements user-provided HTTaP resources that can read or write data in the host program, without race condition. Eventually, the program can in turn control or query external resources or even hardware...
Developed under Linux.
Should work easily with xBSD & MacOS.
Not ported to Windows but should be possible.
This server is not a high-performance, high-bandwidth program. Use appropriate tools such like Apache or NGINX.
This server tries to be safe but it must not be considered secure. TLS/SSL is not used.
This server is not fully HTTP1.1 compliant : it implements only the minimally required features. For example, headers from the client's requests are not event parsed.
This server shouldn't be facing the Internet, it is only meant to be used locally (within a computer or local, DMZed network.)
You provide your own program. An example minimal proof-of-concept is provided as examples/serv_simple.c.
You also provide your entry points to communicate with your code (in development)
Your program must call HTTaP_manager() at least several times per second when in polling mode.
And... that's it.
Check the examples directory to find how to integrate HTTaP into your own application.
Default values are provided in HTTaP.h. You can change them with compile-time flags :
$ gcc -DHTTAP_VERBOSE -DSHOW_CLIENT -I$PWD -Wall examples/serv_simple.c -o serv_simple
You can also tune HTTAP_BUFFER_LEN, HEADER_BUFFER_LEN and MAX_URI_LEN if your platform has a really tight memory budget. Be careful.
The program has no command-line parameters because they can not be easily parsed from within another program. Environment variables are used instead :
Static files are located in a directory, which is by default the current working directory. This directory can be changed at start time with the environment variable $HTTAP_STATICPATH, the program then "cd" to this directory.
MIME types are not guessed and by default the Content-Type is not given in the header. They are explicitly provided by the user in a shadow directory called "...". This subdirectory of $HTTAP_STATICPATH contains the same exact structure but each file contains the plain MIME type instead of actual data.
A "MIME" directory is provided with basic/common types that you can symlink to. If you want more type, IANA maintains an exhaustive list.
Normally : files and HTTaP replies are not cacheable.
Static files can be selectively changed to cacheable by altering their MIME type in the "..." shadow directory. This is done for example for the favicon.ico by adding "\x0d\x0aCache-Control: max-age=200" to the "image/gif" default type. The type is not changed but this adds one more header to the standard HTTP reply. "max-age=200" means that the file can be reused 200 seconds before checking again. This reduces the traffic for the favicon file, which tends to be reloaded very often otherwise.
Selective cacheability in the code is possible but not considered pertinent so far.
The Cross-Origin flag is set once for all at compile time.
However some static files could be altered by changing/altering their MIME type, as already decribed for the caching flags.
No ETag is computed. It can be added to the static files by a script for example, to generate extra headers in the "..." shadow directory.
This software is copyrighted and distributed according to the GNU AGPLv3 or later
The latest source code can be downloaded from Hackaday.io or locally