apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sumeet Singh <sumeet.si...@openwave.com>
Subject Re: [PATCH] RFC: Allow modification/deletion of specific headers in apr_table_t
Date Mon, 26 Apr 2004 05:14:43 GMT
Brian Pane wrote:

>
> On Apr 21, 2004, at 9:11 AM, Sumeet Singh wrote:
>
>> Hi,
>>   In my use-case I am dealing with multiple headers with the same key 
>> (e.g. Cookie), and need to modify or remove a specific header based 
>> on its key and value (e.g. remove a certain cookie header while 
>> leaving the rest in). There is no api in apr_tables that would allow 
>> me to remove a given header instance. apr_table_unset will remove all 
>> cookies. And I can't have my code remove a header from the 
>> apr_array_table_t array because that will render the internal hash 
>> index incorrect. Secondly, eventhough I can modify the value of a 
>> specific header by iterating over the apr_array_header_t, that would 
>> be inefficient because I wouldn't be able to use the internal 
>> index_first and index_last values. Therefore I have written three 
>> functions (patch files attached) and am hoping that the 
>> powers-that-be will be willing to review and roll them into the APR 
>> codeline.
>>
>> 1) apr_table_set_one (apr_table_t *t, const char *key, const char 
>> *oldVal, const char *newVal)
>>   replaces value of header "key" and value "oldVal" with value 
>> "newVal". If "oldVal" is null, then the first occurance of the header 
>> is replaces (this is an optimization for situations where we know 
>> that only one header exists and don't care about its current value). 
>> If the header is not found, then it behaves like apr_table_add.
>
>
> I finally got a chance to read  through the patch.  The code makes 
> sense, but I
> have a question: will apr_table_set_one and apr_table_unset_one provide
> all the functionality you need?
>
> Using Cookie and Set-Cookie  headers as an example, it seems like an 
> exact
> match on the oldVal wouldn't be sufficient.  If your response headers 
> include
> something like this:
>   Content-Type; text/html
>   Set-Cookie: userID=1; max-age=86400; domain=.example.com
>   Cache-Control: private
>   Set-Cookie: sessionID=54321; max-age=1800; domain=.example.com
> and you want to change or remove the "userID" cookie, it's a lot easier
> to do a prefix match on "userID=" than on the entire value of that table
> entry.  (If that table entry was set by some other module, we may not
> know what the full value of that entry is.)
>
That's a good point.

> In the general case, an application might need to:
>   1. iterate through all the elements in a table that match a given key,
>   2. selectively modify the value of one or more of the matching
>      elements, or delete one or more of the matching elements,
>   3. and optionally stop iterating based on some application-defined
>      criteria.
>
Agreed.

> This sounds a lot like apr_table_do, except that apr_table_do
> doesn't allow modification of the table elements.
>
> If there were a variant of apr_table_do that allowed  modification
> of the value (but not the key) of visited elements, and the deletion
> of visited elements, would that work  for your application?
>
Yes that should suffice. Thanks.

-sumeet

> Brian
>


Mime
View raw message