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.)
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.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?
Brian
