httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: HTTP Input header filter
Date Wed, 08 Jan 2003 00:44:00 GMT
Joe Schaefer wrote:

>Greg Ames <gregames@apache.org> writes:
>
>  
>
>>Joe Schaefer wrote:
>>    
>>
>
>[...]
>
>  
>
>>>Just looking over the 2.0 
>>>source, it looks to me like r->headers_in is an empty 
>>>apr_table prior to the apr_table_overlap() call at the 
>>>end of get_mime_headers_core().
>>>
>>>      
>>>
>>I'll take your word for it.
>>    
>>
>
>Please treat the following comments with the appropriate 
>level of contempt, since at this moment apreq_tables are 
>still vaporware...
>
>I've written a table implementation for apreq-2 that 
>superimposes an array of binary trees over the table's
>array entries.  It allows for "dead entries" to appear in 
>the array, so that "restacking" the table entries 
>(and reindexing the superimposed tree nodes) wouldn't
>be necessary when table entries are unset or merged.
>
>The apr_table_overlap call in get_mime_headers_core()
>effectively merges all duplicate input headers, and it 
>uses red-black trees to do so.  If apr_tables were able
>to tolerate "dead entries", it might be possible to port 
>some of the apreq_table implementation to apr (assuming 
>the apreq_table approach proves to be more efficient).
>

Definitely sounds interesting, if it proves faster than
the current APR tables.  One other thing that might speed
up apr_table_overlap is to eliminate the red-black trees.
I added them back when the tables themselves had no
indices.  Now that each apr_table_t contains an internal
index (a crude one, but fairly effective in practice),
we might be able to accelerate the overlap operation by
using that index in place of the red-black trees.

Brian



Mime
View raw message