Roy T. Fielding wrote:
Another reason why apr_hash_t isn't a good match for HTTP headers
is that the same field name may appear multiple times in the request
or response headers (section 4.2 of RFC 2616), but the hash table
implementation is designed around unique keys.
HTTP headers were designed to be processed as a hash table, hence the
rules regarding combining multiple fields with the same name. The only
exception is Set-Cookie, because the folks at Netscape didn't follow
the rules.
Ah, I was wondering why RFC 2109 seemed at odds with 2616 on the
subject of field-combining syntax. :-(
If Set-Cookie is the only exception, it might not be a bad idea to
use apr_hash_t for the request and response headers. I'm even willing
to contribute a patch for this, but it would impact both APR (slightly)
and Apache (a lot). Here's my proposed approach:
1. Add a 2nd create function for apr_hash_t that lets the caller
supply three callback functions:
- a hash function
- an equality-check function
- a concatenation function (if non-NULL, setting x=y followed by
x=y results in concat_fn(y,z) being stored in the table as the
value for x)
2. Change the headers_in and headers_out fields of the request_req
from tables to hash tables. Supply case-insensitive hash and
comparison functions for these hash tables. For headers_out, also
supply a concatenation function that builds comma-separated lists
(and semicolon-separated lists when the key is set-cookie)
3. Change all of the references to headers_in and headers_out in
the core and standard modules to use the hash API instead of
the table API.
4. Document the change so that maintainers of 3rd party modules
know how to make their code compile once again.
Thoughts? Is a change like this worth doing?
--Brian
