httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: PLEASE READ: Filter I/O
Date Fri, 23 Jun 2000 19:20:56 GMT
> From: Greg Stein []
> Sent: Friday, June 23, 2000 1:43 PM
> On Fri, Jun 23, 2000 at 12:30:02PM -0500, William A. Rowe, Jr. wrote:
> >...
> > What about passing buf, buflen, alloc, alloclen on?  That 
> way we don't need
> > to do any realloc if we are growing the buffer by 10 chars 
> and the last 
> > filter just chopped the buffer by 50 chars?
> No can do. The buffer that is passed to the (link-based) filter callback is
> constant. There is no "growing of the buffer" since it is inviolate.

Huh... I'm quite confused.  That implies that my filter to add
a style=dweebish attrib to every html tag without a style attribute
has to:

1) call the next layer twice, or
2) setup it's own buffer, or
3) do it's own pending of buffer overflow (even if I didn't care to.)

[Combining message threads...]
> > It implies
> > my example could split a block, grow it, and all the next layer
> > twice.
> Bing!

This could be simply accomplished in hooks by returning an 
HERE_BUT_I_HAVE_MORE status, which the hook manager could carry down
through the layers, and unwind back to this layer for the next chunk,
no?  Both have their own stack implications, and I think this is where
we need to think long and hard.

Perhaps hooks are the most stable, but allow a second entry point to
the hook manager passing the ap_layer_t arg to allow a segment to pass
through the remaining filters via the hook manager, returning to the
filter, and allow the filter to drop the last manipulation back to
the hook manager, or not by returning an ALREADY_COMPLETED status.

> >...
> > would be the simple example of stripping of 5 bytes.  But this sounds
> > like a hook-based link-list to me (since ap_lwrite needs to parse where
> > layer is in the stack and kick to the next), rather than a simple hook
> > based where 
> > 
> > ap_status_t my_filter_callback(ap_layer_t **layer, const void 
> > 					 *buf, size_t len)
> > 					 *abuf, size_t alen) {
> >      /* **layer is us */
> >      return ap_lwrite(layer + 1, buf + 5, len - 5, abuf, alen);
> > }
> Each callback is passed an ap_layer_t which represents that filter. There is
> a next pointer inside which is used by ap_lwrite().  Example:
> typedef struct ap_layer_t ap_layer_t;
> struct ap_layer_t {
>     ap_status_t (*callback)(ap_layer_t *layer, const char 
> *buf, size_t len);
>     void *ctx;
>     request_rec *r;
>     ap_layer_t *next;
> };
> ap_status_t ap_lwrite(ap_layer_t *layer, const char *buf, size_t len)
> {
>     if (layer->next == NULL)
>         return ap_bwrite(layer->r->connection->client, buf, len);
>     return (*layer->next->callback)(layer->next, buf, len);
> }
> Pretty simple, and it hides the notion of "next" from the 
> filter callback.

Ok, then as far as I can tell, there is no difference between hook
based and link based filters other than:

L) link based chain and keeps appending (small bits) to the stack
   and calls the next participant via ap_lwrite.  It dies by
   refusing to pass on the message.

H) hook based chain is implicit on return to the ap_lwrite (or
   equivilant) and dies by returning an explicit status as such.

Every other part of this argument should be stripped out and
discussed seperately.  The ap_layer_t and it's contents, and the
buffer and it's contents are discussions into and of themselves.

What, at their essence, do the hook or link calling mechanism buy
us?  I can see hook is less prone to stack faults (let's not forget
any auto variables created on the stack for each iteration).

Both can manipulate the sequence and drop out future steps if they
were granted a volatile version of the layer structure, but I think
that's all mute.  Both could tweak layer->next and change the

I'll let you both answer if there is anything I've missed that can't
be accomplished in either, let's resolve this question, and go on
to the next little bit so we get can collect our forward momentum.


View raw message