httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Filtered I/O ... again. :-)
Date Wed, 31 May 2000 21:30:39 GMT
On Wed, 31 May 2000, Jeff Trawick wrote:
> I don't understand why a filter has to be able to tell the caller that
> it hasn't processed everything

Agreed. A filter probably does not need to do this (for either the hook-
or link- based designs).

> mod_include needs to be able to signal an error if the filter is
> removed but he is still waiting for the rest of an SSI tag.

Correct. At the end of a request (defined how?), Apache needs to inform
the filters to flush any internal buffers. This is the point where SSI
could generate a syntax error for an unfinished tag.

I do not have a good handle on where/how the "end of request" is signaled.
I believe when the "content generator" is done, it must signal the EOF
somhow. That would then get propagated through the filters to get them to
flush their internal buffers.

In the link-based design, I would simply use a zero-length buffer as the
indicator to flush. For example:

ap_status_t mod_include_callback(ap_layer_t *next, const void *buf,
                                 size_t len, request_rec *r)
    if (len == 0) {
       /* end of input. flush internal buffers. */

The presumption, of course, is that the callbacks are not called with
len==0 unless it is the EOF state.

Hmm. The BUFF code has a concept of "end of response" so that it can
generate the terminating chunk marker. Somewhere around there, we could do
the following:

    if (r->first_layer != NULL) {
       r->first_layer->callback(r->first_layer->next, NULL, 0, r);
    /* send the end-of-response chunk marker */


Greg Stein,

View raw message