Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Tue, 10 Jul 2001 18:54:54 -0700
From: Brian Pane <bpane@pacbell.net>
Subject: Hash tables and request headers Re: observations on fragmentation in
 SMS pools
To: apr-dev@apache.org, new-httpd@apache.org
Message-id: <3B4BB1EE.9040707@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628
References: <20010710012924.O18140@angua.rince.de>
 <Pine.LNX.4.30.0107091647300.27684-100000@koj.rkbloom.net>
 <20010709201426.B1138@covalent.net> <20010709221907.E2369@ebuilt.com>
 <3B4AA625.3040706@pacbell.net> <20010710151846.B898@waka.ebuilt.net>

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