tipidee is fully functional, and you are encouraged to use it; however, it is not yet considered complete. There are some optional features of HTTP that would be nice to have, and that may be implemented at some point down the line.
HTTP Basic Auth is ubiquitous; and even busybox httpd implements it. It sounds silly not to have it; it would be good to add to tipidee.
However, how to implement HTTP basic auth in a secure way is not entirely obvious. Credentials should not be stored under the document root; passwords should not be stored in plain text; the credentials database should have more restrictive permissions than the configuration database; and the credentials database should be easily regenerated.
I'm leaning towards a cdb credentials database, distinct from the configuration file; but this requires a second offline text file processor, for the credentials file, and adding support for a second cdb mapping in various places in tipideed. That was more complexity than I wanted for an initial release; it's not urgent, it can wait.
ETags are unique identifiers for resources that clients can use to cache data, and only download resources they do not have. Like ranges, ETags support can save bandwidth.
The problem is that creating ETags is pretty resource-intensive on the server side. You have to maintain an ETag database, and update it any time a document changes; alternatively, you have to dynamically hash a whole resource before deciding if you're serving it or not. Both paths are riddled with traps and design challenges, and neither is appealing to a server like tipidee aiming at simplicity and efficiency. ETag support may come one day, but it won't be soon.
If tipidee compares to big Web servers performance-wise, which is the expectation, it is quite possible that the performance bottleneck becomes the CGI protocol itself, i.e. the need to spawn an additional process for a dynamic request. In this case, it would be useful to support other methods of communicating with dynamic backends.
A module system, or embedding language-specific support into tipideed, is out of the question, because it goes against the design principles of tipidee; however, FastCGI support sounds like a possible path to more performance.