Filters for Apache - would this work? (fwd)

[Brian Behlendorf <br...@organic.com>]

Anyone care to comment?

	Brian

---------- Forwarded message ----------
Date: Mon, 15 Jan 96 19:05:52 -0500
From: Nathan J. Kurz <na...@tripod.com>
To: apache-users@trytel.com
Newgroups: comp.infosystems.www.servers.unix
Subject: Filters for Apache - would this work?

I posted a while ago to comp.infosystems.www.server.unix about making a filter
module for Apache, such a request for the file testfile.html.bork would cause
the file testfile.html to be processed by a text filter (in this case the
Swedish Chef program) before being sent to the client.  Even further, I'd love
to be able to chain filters together, such that I can request things like
testfile.html.bork.gz and get a gzipped version of the encheferized html page.
If possible, I'd like it to work for .shtml pages as well.

I got a nice response as to how mod_action.c might be used as a starting
point, and some information that such filters were anticipated for future
versions of Apache.  I've spent some time looking over mod_cgi.c and
mod_action.c, and think I might have an idea that would work.  But before I
work on it, I figured I should ask someone with a clue if it stood a prayer.

My scheme in summary:
1)	AddType filter/bork .bork  
	Filter  filter/bork /usr/local/bin/chef

2)	Have the handler start /usr/local/bin/chef with spawn_child()
	Output of 'chef' goes to r->connection->client, plus or minus some
	fudged headers.

3)	Issue an internal_redirect() (or process_request_internal() ) with
	r->connection->client set to the input of 'chef'.

4)	2) and 3) repeat until something actually handles the request.  At
	this point, r->connection->client is written to by the handler, which
	points to the input_fd of the first filter.  The first filter's output
	goes to the next filter, until the last filter -- whose stdout is the 
	original r->connection->client.

I'm unsure of how to deal with the headers, though.  Encheferizing and
gzipping the mime type would probably be a no-no.  I could do something like
putting in an r->no_headers option, and change all the handlers to obey it,
then call send_http_headers at the end... but this is ugly.  Or I could make a
seperate fd called r->connection->client_headers, and send the headers through
this (unfiltered) channel.  But what about filters that change the mime type
of the contents -- like a gif to jpeg filter...  Hmm, maybe I should scale
back my plans a bit, to only deal with text/html -- or at least mime types
that don't change.

Thoughts appreciated.  Especially those that tell me to quit wasting my time
and go home and go to sleep :).  And what is this 'Protocol Abstraction' that
Apache is heading towards?

nate@tripod.com
http://www.tripod.com