> From: Cliff Woolley [mailto:[EMAIL PROTECTED] > > On Fri, 31 May 2002, Ryan Bloom wrote: > > > I considered that, but I am actually thinking of the future, where there > > are different types of data. For example, when we want to send the > > headers down the filter stack as a part of the brigade, that is metadata > > and should be marked as such. However, the headers are likely to be in > > HEAP buckets, which means that the metadata flag really has to be in the > > bucket itself, not the bucket_type. > > That's a different definition of metadata than the one I was using, in > that by that method the length would be non-zero. I always envisioned the > header data as being in a new type of bucket, one which contains an > apr_table_t as metadata and is zero-length. The length should always mean > data, never metadata.
Length does always mean data, but length has nothing to do with this discussion. As I said the other day, there are two types of metadata, filter metadata, and request metadata. This flag currently refers only to filter metadata (which means that the bucket itself is the metadata), but in the future it must also be useful to state that the data contained in the bucket is metadata, this would be request metadata. Even if the headers start as a special bucket, at some point in the filtering, they could easily be converted to a HEAP bucket. In fact, most filters will convert headers to HEAP data so that they are easier to read and modify. The length field should ALWAYS represent the amount of data stored in the bucket that will be sent to the client. Ryan
