Re: cvs commit: apr-serf/include serf_buckets.h

[Cliff Woolley <jw...@virginia.edu>]

On 1 Jul 2002 jerenkrantz@apache.org wrote:

> jerenkrantz    2002/07/01 08:47:54
>
>   Modified:    include  serf_buckets.h
>   Log:
>   The authentication and header buckets need a pool so that they can allocate
>   memory on bucket_read
>

You can't have metadata buckets that return data on an apr_bucket_read()
call.  apr_bucket_read() is only supposed to return *data*, and the data
returned should be of length at most e->length (which is zero for metadata
buckets).  If you want to get the metadata out, you need a type-specific
call.

--Cliff

Re: cvs commit: apr-serf/include serf_buckets.h

[Justin Erenkrantz <je...@apache.org>]

On Mon, Jul 01, 2002 at 12:12:31PM -0400, Cliff Woolley wrote:
> You can't have metadata buckets that return data on an apr_bucket_read()
> call.  apr_bucket_read() is only supposed to return *data*, and the data
> returned should be of length at most e->length (which is zero for metadata
> buckets).  If you want to get the metadata out, you need a type-specific
> call.

Yeah, I see I left the bucket types as APR_BUCKET_METADATA.

I wasn't thinking of them as pure metadata - because they implement
a read function they do have data.  It's just that the code has to
be careful not to mix them up with the real data.

What my vision was of the following:

An HTTP header output filter that does:
{
 ...create the request line bucket...
 ...add it to a new brigade...
 APR_BRIGADE_FOREACH(...) {
  if (APR_BUCKET_IS_HEADER(e)) {
   ...append the bucket to the new brigade...
  }
 }
 ...concat the rest of the original brigade to the new one...
 ...pass it on...
}

An HTTP header input filter that does:
{
 Create the status bucket corresponding to the response line
 while we're not seeing a CRLFCRLF
  create header buckets out of that line
 ...pass to the next in line...
 ...remove ourselves...
}

The only problem is how to handle duplicates on the output.  For some
headers, it is okay to have duplicates, for others (C-L), it's not
okay.  That'll require some thought as how to handle that correctly.

And, I think that we'll also need a variant of the header and status
bucket creation functions to allow a single string with pointers
where the key and value are.  Because when we read the
CRLF-terminated line on input, we get:

Cool-Header: Awesome-Value

We can just say at offset 0 is the key with length 11 and the value
is at 14 until \0.  This will also allow us to just return a
single string value.  But, for the output side (where headers are
created), it doesn't make sense for this type of delimiting to
occur.  Hence, two bucket creation functions for one bucket.  Is
that allowed?  -- justin