On Mon, 1 Oct 2001, Greg Stein wrote: > Unlike Apache, I believe we should design the serf to pass the HTTP headers > through the filter chains. Apache couldn't really do it because of backwards > compat issues (the presence of r->headers_in and r->headers_out). > But we're starting fresh. Adding a header bucket will allow filters to > examine the request/response headers to control their function and to > manipulate the headers.
Okay. > I believe a header bucket is simply an apr_hash_t of headers. Adding and > looking up headers requires a bit of extra glue to lower-case the header > name. Using a hash means it is very easy to set aside the headers (waiting > for the end-of-header bucket so a header can analyze the full set of hdrs), > manipulate them, and to gather them up (we need to add a "merge" function to > the hash table, although merging headers requires a bit more than simple > overlap). I assume you mean that the serf would see a bucket of type HTTP_HEADERS and would then call some bucket-type-specific function to handle the bucket. What would this bucket look like through the real bucket API? Like a metadata bucket (ie, length=0, apr_bucket_read() returns nothing), or would calling apr_bucket_read() on this puppy actually format the headers for output? Anyway, I'm not sure I like introducing the concept of the caller having this much information about an individual bucket type. But I can't think of a more efficient way to do it. --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
