httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] chunking filter.
Date Wed, 16 Aug 2000 22:12:12 GMT
On Wed, Aug 16, 2000 at 02:42:13PM -0700, wrote:
> On Wed, 16 Aug 2000, Greg Stein wrote:
> > On Wed, Aug 16, 2000 at 01:45:58PM -0700, wrote:
> > >...
> > > > Hmm. The chunking filter needs to watch out for brigades that are zero
> > > > length. I think the right answer is:
> > > > 
> > > > *) if the brigade is zero length, then do not insert a chunk header. there
> > > >    may be other metadata buckets in the brigade, so it must still be passed.
> This is a non-issue.  The brigade should never be zero length.  If a
> filter or handler is actually sending a zero legnth brigade, then they
> deserve what they get.  This is an undefined operation, and we don't need
> to handle it.

Well, I think it is just a bit too easy to create, say, a file bucket and
then pass that into the filter chain. Some filter in the chain reads the
contents out (oops! zero length) and passes them down. Or simply some code
that looks like this:

    void foo(const char *s)
        ap_rputs(s, r);

And somebody calls foo() with an empty string. I inserted a fix for this
latter case (in ap_rputs()) to check for zero length strings. But the
general problem of creating zero-length brigades exists. I think it would be
prudent to watch out for them. *Especially* if we're computing the length
anyhow. We may as well handle the case if we see zero-length.

> > > > *) if the brigade is not zero length, then add the chunk header and trailing
> > > >    CRLF.
> This is already done.

Of course. I was simply listing the three cases.

> > > > *) if the brigade contains EOS, then append the right "termination" stuff
> > > >    for the chunking. the appending is really that... the termination text
> > > >    must come before the EOS bucket :-)
> As is this.

In an updated patch, I presume? Great.

> > The content length may be zero, but there may be other buckets that are
> > "meta operations" (if you will) that do need to be delivered. EOS is one
> > such operation. Because of this, the chunk_filter does need to follow the
> > three-step logic above (or something close/similar).
> The chunk filter does not need three-step logic.  It needs to handle two
> cases, which are already done.  If there are other special case buckets,
> then the chunking filter will need to be told about them.

Third party bucket types may have these meta-operation / semantic-only
buckets. A general policy is in order: a bucket may be zero length because
it represents something other than content. Therefore, a brigade may be zero
length because it represents something other than content.

The EOS bucket is one such bucket. The chunking filter knows (specifically!)
about EOS because it must complete the chunk response with the appropriate

> > In my latest fix to http_protocol.c, I hypothesized two more: SUB_EOS
> > and FLUSH.
> Having given this just a tad bit of thought, I am beginning to think the
> SUB_EOS is a bad idea.  The best way to do this, is to have the
> sub_request insert a sub_request core filter, which strips out the EOS
> that it receives.

Ah. This is a good solution. If we insert content filters on the subrequest,
they could look for EOS just like when they are on the main chain.

Good call.

> The flush may also be a bad idea.  A handler can say,
> flush the data to the network, but that doesn't mean that the other
> filters have to respect that.  It is likely a bad idea to give the handler
> that much control over the filters.

A FLUSH bucket would always be advisory. However, I *do* believe that a
handler should be able to *advise* the filters to "send what you can now."
Consider the case of a content handler that wants to spit out a block of
HTML that tells the user to wait a moment while the rest of the page loads
(which is going to take a while due to database queries).

Another name would be fine. It doesn't necessarily have to completely flush
everything, but something more along the lines of "send what you can".

> > But your point about zero-length *content* is absolutely correct. Hmm. I'll
> > make a couple fixes to minimize that possibility.
> I would like to commit the entire patch, including the fix for the
> ap_add_filter patch soon.

I'm not sure on the add_filter changes yet (LIFO vs FIFO seems to simply
reverse the problem rather than generically solve it).

The chunking filter patch looks close. The EOS and output-last-chunk needs
to move from the finalize function to the chunk_filter. Did you do this part


Greg Stein,

View raw message