apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: Observations on fragmentation in SMS pools
Date Tue, 10 Jul 2001 06:52:21 GMT
Justin Erenkrantz wrote:

>On Mon, Jul 09, 2001 at 08:14:26PM -0700, Jon Travis wrote:
>
>>Tables should definitely be moved to APR-util if they are to remain.  As
>>for Apache, there are better structures that dictate general order than
>>the table.  IMNSHO, the only reason tables are still in Apache is inertia.
>>Nobody wants to go through and change everything to a more sane data
>>structure.  Case insensitive searches -- linear search time over the
>>table ... ugh.  
>>
>
>One problem with hash tables is that if you want to retrieve a HTTP
>header, you now need to have it be the same case as it came in (unless
>you are normalizing every call).  RFC 2616 states that (Section 4.2):
>
>"Field names are case-insensitive."
>
>Therefore, if the client sends:
>
>CoNnEcTiOn: Keep-Alive
>
>it should respect that.  And, this data structure is primarily used for 
>storing HTTP header info (I'm not sure about mod_mime).  I'm not aware 
>of any browsers that do this, but I'd bet someone will because the RFC 
>says you can.  (It's possible I'm misinterpreting the RFC, wouldn't be 
>the first time...)
>
>AFAICT, this doesn't call for a true hash table or a true array.  It's 
>something slightly different.  Any data structure which replaces tables 
>needs to be able to handle the case-insensitivity gracefully.
>
>Just want to make sure that any solution keeps us correct to the RFC.  
>-- justin
>

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.

--Brian



Mime
View raw message