BACK
Features
dpfTVS was written in C++ from scratch and it has the normal features like support for CGI or the so called cheap virtual-servers. It supports some kind of user identification, but not in the rfc defined way. And so on. The thing I needed was a MUGI interface. This is short for "my uncommen gateway interface". Basically it provides a routing like service, shoving the complete request data via a tcp socket to an already running program. It doesn't really matter where this demon is located, it can reside on the same machine, somewhere in a lan or even some place else in the internet. It will however act as a buffer to the users out there, so the body size of a request will be known in advance, the response will be checked against ETAGS and provided timestamps to ensure that only needed data goes to the browser. Of course byte-ranges are processed too. A mugi can order the server to send a file, even ones outside the regular allowed directories or create a loopback to an internal location to be processed instead. So a mugi can also be used as a filter. CGI scripts need a lot system resources and are therefor slow. A MUGI request is more than 10 times faster done. As a MUGI is only started once it can make use of extensive configuration files and often needed data can be loaded/cached in advance making it a lot more flexible than a CGI script. It also only uses 1 socket, where CGI needs at least 2 pipes.

What it supports:
  • uses dynamic pre-forking or pre-threading
  • quite fast, secure and scalable
  • GET, HEAD, TRACE for static content
  • GET, POST, HEAD, TRACE for CGI, MCGI and MUGI
  • OPTIONS is forwarded to the scripts
  • compliant to http/1.1, http/1.0 and to http/0.9
  • persistent connections for http/1.1 and keep-alive for http/1.0
  • request pipelining for http/1.1
  • virtual servers via the complete host name
  • CGI/1.1 compliant interface, with some additional environment variables
  • MCGI interface, slightly changed CGI to support a directory tree
  • MUGI interface, for direct forwarding and for a set of registered mugi servers
  • supports timestamps (if-modified-since, if-unmodified-since, if-range)
  • supports ETAGS for cgi/mcgi/mugi (if-match, if-none-match, if-range)
  • simple byte ranges (one range per request, multiple ones get combined if possible)
  • User customizable MIME types
  • static cache (files pre-loaded at startup) for highest speed without harddisk activity
  • half-static cache, files get pre-mmapped and are only updated if changed

What it doesn't support:
  • (d) user identification
  • (t) dynamic file cache
  • (t) support for customizable error responses
  • (t) OPTIONS for static files
  • (*) multiple listen ports
  • (*) referer checking against traffic theft
  • (~) encryption (https via ssl)
  • (~) support for transfer encodings other than chunked
  • (~) IPv6 support
  • (~) multiple byte ranges in one request (only the first in a list is processed currently)
  • (?) FastCGI
  • (?) other CGI like interfaces
  • (?) log files of any kind.
  • (?) PUT, DELETE (perhaps via external filter?)
  • (?) on the fly compression of text based files
  • (-) CONNECT
  • (-) built-in directory services
  • (-) content negotiation
  • (-) reconfiguration at runtime.
  • (-) (caching) PROXY features
  • (-) ftp
  • (-) loadable modules. mugi is in most cases only slightly slower anyway...

(*) are things I plan to add in the near future
(~) are things that might be added eventually
(?) you guessed right, don't know yet, give me your opinion
(-) not planned to be added
(d) is actually already built in, but disabled due to the incomplete user-management (t) is currently closed alpha tested
BACK