> From: Cliff Woolley [mailto:[EMAIL PROTECTED]] > > On Fri, 31 May 2002, Cliff Woolley wrote: > > > e->length == 0 does NOT imply it *has* to be metadata. It could just be > a > > data bucket that's empty. On the other hand, if it's metadata that DOES > > imply e->length == 0. It's a one-way relationship, not an if-and-only- > if. > > It turns out that most filters won't much care... if they act on data in > a > > bucket and the bucket contains no data, they should just pass it on > along. > > But it could easily be an empty HEAP bucket, and that's definitely not a > > metadata bucket. If you're going to have an APR_BUCKET_IS_METADATA() > > macro, it will have to test a new "ismetadata" flag in the > > apr_bucket_type_t. But I'm -0.5 to that too, because it leads filter > > authors to believe that there should be a distinction between metadata > > buckets and empty data buckets when that's not the case. > > Hmmm... okay, on second thought, +1 to the second approach. One could > make the valid argument that it's safe to remove zero-length buckets if > and only if they contain no metadata. How can you know which ones those > are without asking the bucket itself? You can't. That requires you to > pass on *all* zero-length buckets, which is a waste of time. So I'll > agree to adding a field to apr_bucket_type_t to allow the bucket to > indicate whether it contains metadata or not [ie, whether or not > zero-length implies "no useful information here"].
I was half-way through my response when you sent this. :-) I will make the change today. BTW, this is also important, because there are actually 2 different types of metadata: metadata about the filter, and metadata about the request. Currently, we only send the former down the filter stack, but at some point, we are going to send headers and other request-based metadata down the stack, and the new flag will be important at that point too. Ryan
