You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Robert S. Thau" <rs...@ai.mit.edu> on 1995/07/08 17:26:57 UTC

Re: it's late...but here is an idea

   Date: Sat, 8 Jul 1995 06:00:03 -0700
   From: Cliff Skolnick <cl...@steam.com>
   Cc: new-httpd@hyperreal.com

   Basically I want to do server side parsing in addition to the
   standard server side include parsing.  Doing it 
   instead of it easy, in addition to is a bit harder, but still
   can be done.

I'm not quite sure I understand what you're getting at there...

   My suggestion (and I can work on this) is to add a parsing handler.
   The framework would open the file (instead of opening it itself as
   mod_include.c does now) and pass a pair or file descriptors to
   the functions.

   In the simple case, the input fd would be the file, output fd would be
   the socket.

   [FILE] -> handler 1 -> [Socket]

   for two parse handlers,

   [FILE] -> handler 1 -> [Pipe] -> handler 2 -> [Socket]

   Not the most efficient, but if your using two handlers anyway :) Either
   way, beats forking off a CGI.

   What do you think?

I think we need to think it over.

As a first note, the cost of the scheme above really is a bit high.
As near as I can tell, the server more or less has to fork so that
your "handler 1" and "handler 2" run in separate execution contexts,
and fork() is something that I at least am trying to get away from.
("handler 1" and "handler 2" will generally deadlock if they are run
in the same process, and are processing a document of nontrivial size
--- "handler 1" writes enough to fill the pipe and then blocks,
guaranteeing that "handler 2" will never be run to read it back out).

I had been thinking about giving modules some kind of access to SSI,
which is at least one of the things your scheme would accomplish, but
along very different lines --- basically, of keeping the current SSI
includes module as a framework, but giving *it* an API which would
allow other modules to register their own SSI directives.  This avoids
the difficulties involved in trying to somehow stack response
handlers, and just as importantly, it guarantees users some basic
consistency in the syntax of new directives, or at least in the ways
those new directives are set off from the enclosing text (which might
otherwise be all over the map).

In closing, my general feeling is that if you want to ship soon, then
it's too late to get something like this into the first release --- it
has to be designed right, or it will come back to haunt us.

rst