On Mon, Oct 01, 2001 at 11:35:10PM -0700, 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. > > 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 would say that there should be a response object that a particular filter should read the headers and store them in a hash and then the headers (as a specific bucket themselves - each header is a bucket itself) can be passed down the chain like any other bucket after it has been recorded. I don't think it is necessary for all filters to record each header individually (you have a response object to deal with storing it - actually, it should run at the end of the HTTP Header chain - so that filters could modify the headers as they are passed down from the HTTP protocol reader - then the filter that records the header consumes it and doesn't pass it down anymore). The bucket for headers is simply a string with a position/pointer of the : marked. At least, that's how I see it. It is fairly straightforward to get the value and name out of that. Reading the bucket via bucket_read should just return the string. But, if you know it is a header bucket, you can call the special ops to get the name/value pairs. MIME folding makes things a bit interesting though. Not sure exactly how that'd work out though. Feasible. This is what makes ap_getline in httpd such an oddball to replace because it cheats and looks ahead to make sure that the line isn't folded. Not typically ideal, but necessary given the HTTP semantics. We may be even able to cheat and just expand all of the folding - the HTTP input filter (i.e. reading from the socket) would just handle the MIME folding and send only key-value pairs down. If it is folded or has multiple values, each value is sent separately down the filter stack. It'd be easy to work with it that way, I think. When the HTTP input-filter has read EOH (i.e. two CRLFs), it sends that down and now we deal with content-only at that point (well, excepting trailers w.r.t. chunked-encoding). -- justin
