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 Tue, 27 Apr 2004 22:53:55 GMT
    If you ask me, I can write the new functions (i.e. the apr_table_do 
- type functions you described) and submit a patch for review. Let me 
know ...


Sumeet Singh wrote:

> 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

View raw message