httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey W. Baker" <>
Subject Re: layered I/O (was: cvs commit: ...)
Date Wed, 29 Mar 2000 10:15:30 GMT
On Wed, 29 Mar 2000, Roy T. Fielding wrote:

> >Selection of IO Layers
> >
> >The core selects a source module and IO layers based on the urlspace
> >configuration.  Content might be generated by mod_perl, and the result is
> >piped through mod_chunk, mod_ssl, and mod_net, in turn.  When the content
> >generator runs, the core enforces that the module set the content type
> >before the first call to ap_bput.  The content type is set by a function
> >call.  The function (ap_set_content_type(request_rec *, char *)) examines
> >the content type and adds IO layers as neccessary.  For server parsed
> >html, the core might insert mod_include immediately after mod_perl.
> The problem of thinking of it that way is that, like Dean mentioned,
> the output of one module may be filtered and the filter indicate that
> content should be embedded from another URL, which turns out to be a
> CGI script that outputs further parseable content.  In this instance,
> the goal of layered-IO is to abstract away such behavior so that the
> instance is processed recursively and thus doesn't result in some tangled
> mess of processing code for subrequests.  Doing it requires that each
> layer be able to pass both data and metadata, and have both data and
> metadata be processed at each layer (if desired), rather than call a
> single function that would set the metadata for the entire response.

Ah yes, module B produces output parsed by upstream module A, which never
even sees it.  I knew there must be a problem.

Shooting at drawing board.


View raw message