small todo list

Note: this list is updated every now and then and doesn't necessarily represent the exact state of development. Use it as a rough overview.

  • not thread-safe config handling (setups are only allowed in startup mode and don't need to be thread-safe)
    • review
  • core
    • out-of-fd handling should be (only) in the main worker
    • X-Throttle (lua-api for throttle handling?) ?
    • limit request/response header size, request url length
    • option for directory of upload tempfiles
    • wait for listen-sockets from angel from LOADING -> SUSPENDED
    • config include *: sort filename
  • generic "data-retrieve/send" api:
    • register backends with a identifier; provide backends from modules (lua callback (in separate worker threads), sql backends, memcache, files?, counters,...)
    • callbacks take a vrequest context (only in same thread - copy data to other threads if needed)
    • callbacks take additional string parameter?
    • retrieved/sent data are raw byte streams
    • use for:
      • page caching
      • dynamic ssl certificates
      • dynamic vhost configs
      • status counters (backends in use, errors, ...)
    • backend must be registered before use
  • angel
    • REWRITE: remove instance from config concept
    • log rotation (or use the zero downtime restart?)
    • control socket interface
    • angel-control util
    • reload angel config (changing number of fds, ...) (re-exec binary after updates?)
    • pipe logging
  • log
    • scheme:// prefix
    • support for pipes
    • open log files with angel
    • print "startup" (== if logging is disabled) log messages to stderr/angel if the log level target isn't /dev/null
  • plugin api
    • inter-plugin api
    • plugin data per client ip address
      • can be used for bandwidth throttling, limit requests per second, limit concurrent requests etc
      • has to be shared among all workers so locking needed?
      • maybe let main worker do the lookup/removal in a radix tree so no locking needed for that and let plugin make sure it's threadsafe when modifying
  • modules
    • port remaining modules from 1.x
      • mod_extforward
      • mod_ssi (this probably should be realized as FastCGI application) ?
      • mod_ajp13 ?
      • mod_trigger_b4_dl ?
      • mod_usertrack ?
      • mod_(web)dav ?
    • new concept for:
      • mod_{my,pg}sql_vhost (load complete config instead of just doc-root)
      • mod_rrdtool
      • mod_geoip
    • sql vhost (lua handler go generate actions from db rows?)
    • mod_auth_dovecot
    • add even more innovative modules :)
  • mod_auth
    • digest authentication
  • mod_status
    • show timeout in duration column like "5/120" ?
  • mod_dirlist
    • generate stat dirlist/html body async, using tasklets (to allow etag-cache-hit)
  • mod_deflate
    • proper detection of client supported methods (current "broken": strstr with supported methods, check whether method is the start)
    • add "force" modus to enforce a specific compression method
    • add "enflate" or "fix compression" action to deflate the content if the client doesn't understand the current encoding
      The idea behind this would be something like this:
      memcached.lookup ( ..., ${ deflate.fix; deflate; }, ${
          deflate.enforce "bzip2";
  • mod_fastcgi
    • keep-alive connections
  • mod_memcache
    • store http headers, so we can cache deflated content too
  • mod_proxy
    • make HTTP/1.1 downstream requests
  • mod_balancer
    • rename to mod_balance
    • add options for backlog size, ...
  • mod_status
    • separate tab for connection details; select list of available tabs in config
    • somehow access stats of old instance (over angel) after graceful restart
  • stat-cache:
    • revalidate dirlist entries with stat() after cache hit ?
    • purge invalid entries (stat()/open() failed), i.e. remove from hash tables
    • check for normal stat entry, stat() and S_ISDIR before queuing dirlist job
    • reset ttl after revalidating entries
    • limit for hash tables?
    • check symlink/symlink-if-owner-match
  • build systems
    • at least one build system should provide static builds

Updated by stbuehler over 10 years ago · 63 revisions