On Tue, Oct 02, 2001 at 02:42:30AM -0400, Cliff Woolley wrote: > On Mon, 1 Oct 2001, Greg Stein wrote: >... > > 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?
Hadn't thought that far :-) My *main* point was to get the headers sent through the filter chain. One of the more broken aspects of httpd's filters is how it reaches "outside" of the filter (chain) context and examines the request_rec or conn_rec. Since those two structure exist "outside", they do not participate in the flow, so it is very difficult to manage inspection and changes of them through the filter stack's control flow. IOW, I see f->r and f->c as a hack that should go away. Filters should operate in a completely content-free manner. Reaching "outside" severely limits their utility. Witness the proxy needing to create a fake requset_rec to satisfy the needs of the DECHUNK filter (dunno what it does now, but I would surmise it is still needed). > 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. Today, callers (can) know quite a lot about buckets and how they are constructed. Buckets can be used in two ways: 1) pure data. who cares what is in them or what they are. just read() them 2) specific knowledge: is it an EOS? is it a FILE, so I should mmap it? is it a FILE so I can sendfile() it, or is it data that I should writev()? The HTTP_HEADERS buckets would be no different. In that respect, I would think that read() would format the bugger and return that. And yes: this *does* mean that willy-nilly read() calls should be avoided. But we *already* knew that (httpd reads buckets way too much, IMO). EOH would return "\r\n" :-) Note that many filters wouldn't even have to see those buckets if we use a hook to insert (more output) filters when the HTTP_OUT filter finally sees an EOH. Similarly, input filters would not be inserted until some upper level doodad sees the EOH generated by the HTTP_IN filter. If a filter *does* see it, then it operates just like any other content. As with anything, we just need to ensure that code that processes content knows the difference between HTTP headers and the body (or delay the insertion so it doesn't have to know). Cheers, -g -- Greg Stein, http://www.lyra.org/
