What I want out of an HTTP server is pretty simple, but hasn’t been completely done, or if it has, is kludgy and hard to maintain.
I want content-type handlers that pay attention to the Accept: header. If I define that files ending in .tl get passed through a pipe to /usr/bin/textile-format to turn into text/html, and through /usr/bin/html2fo to turn text/html into application/xsl+fo, and then through /usr/bin/fopdf to make application/pdf, then it should instantiate those three in a pipe, and do it! It’s not that hard! GStreamer does it for media files, why can’t the web server for text files?
Instead of
Action application/x-httpd-php /cgi-bin/php.cgi
AddType application/x-httpd-php .php
and hope it spits out the right thing and to magically turn .php files into html (or whatever the script decides), it should be
Transform application/x-httpd-php */* /cgi-bin/php.cgi
Transform text/html text/plain "/bin/lynx -dump"
Transform text/html application/xsl+fo /usr/bin/html2fo
Transform application/xsl+fo application/pdf /usr/bin/fopdf
All this ignores the (relative) inefficiency of instantiating programs in a pipeline all the time. Honestly, I think that if things are small and modular like this, it’s not a problem; cgi instantiation time is only a big deal when you have large interpreters and a big gob of code to compile. However, if it became a problem, I can certainly imagine inventing something like FastCGI for transform handlers. Imagine this:
Transform application/x-httpd-php */* fastcgi2:///var/run/php/php.sock
Transform text/html text/plain fastcgi2://unixserver:3503/lynx
Transform text/html application/xsl+fo fastcgi2+spawn:///usr/bin/html2fo
Transform application/xsl+fo application/pdf fastcgi2+spawn:///usr/bin/fopdf