apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr-util/include apr_buckets.h
Date Sun, 02 Jun 2002 00:25:33 GMT
On Fri, May 31, 2002 at 02:19:16PM -0700, Ryan Bloom wrote:
> 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.

Woah. Are you seriously suggesting that every time we call bkt->read(), that
we must also check bkt->is_metadata? No way. That just isn't going to

> 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.

No. A HEADER bucket will use a hash table. We want it to be structured data,
not some flat serialization of a header.

> The length field should ALWAYS represent the amount of data stored in
> the bucket that will be sent to the client.

Your hash table is going to be serialized by HTTP_OUT. Until that point, the
bucket has no content -- only "metadata". "metadata" in this sense is
everything outside of the raw content of the response. The bucket length
corresponds to that response, not to some conception of what HTTP_OUT is
about to do.

The fundamental problem is that attaching is_metadata to each bucket, and
saying that some buckets values that come back from read() *might* be
metadata, will absolutely and completely bust the whole notion of buckets.
It means that *every* read will need to first test whether it really should
be "reading" this bucket.

No no no. bkt->read() is about raw response data. Until HTTP_OUT serializes
the headers, then a HEADER bucket has no response data, so its length will
be zero. *After* the HTTP_OUT filter, you'll just see HEAP buckets or
somesuch, but nobody is going to be concerned about the distinction between
headers, content, or trailers at that point -- you're probably just dropping
the bits into the socket at that point.

-1 on per-bucket metadata flags. It goes in the type.


Greg Stein, http://www.lyra.org/

View raw message