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).
Absolutely agree.
> 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.
A well stated goal.
> 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 think an alternative solution is to give each header it's own bucket.
This may seem like significant overhead at first, but it actually isn't
that bad, and it has some good side-effects as well:
- we don't have to do memcopys everywhere, we can do some trickery with
string pointers to the original buffers (and even counted strings).
- we avoid the big constants in dealing with the hash.
- we allow filters to get at the headers sooner (faster responding
client apps).
- not all headers happen at the front of the request/response streams.
(think footers, not to mention delayed headers like what Roy was talking
about for HTTP/2.0 (aka Wakka))
-aaron
