https://bz.apache.org/bugzilla/show_bug.cgi?id=62380
--- Comment #8 from Luca Toscano <[email protected]> --- Changing mod_headers might not be as easy as I thought. The following simple patch solves this specific use case: Index: modules/metadata/mod_headers.c =================================================================== --- modules/metadata/mod_headers.c (revision 1843742) +++ modules/metadata/mod_headers.c (working copy) @@ -791,9 +791,12 @@ } break; case hdr_set: - if (r->headers_in != headers && - !ap_cstr_casecmp(hdr->header, "Content-Type")) { - ap_set_content_type(r, process_tags(hdr, r)); + if (r->headers_in != headers) { + if (!ap_cstr_casecmp(hdr->header, "Content-Type")) { + ap_set_content_type(r, process_tags(hdr, r)); + } else if (r->err_headers_out == headers) { + apr_table_unset(r->headers_out, hdr->header); + } } apr_table_setn(headers, hdr->header, process_tags(hdr, r)); break; But then how about 'merge', 'setifempty', etc..? The fact that there are two separate list of headers ('onsuccess' vs 'always') makes it really tricky to fix all the use cases without introducing regressions. For example, how is it the right way to handle the following example? 'onsuccess' header list -> X-Foo: bla 'always' header list -> [] Header always merge X-Foo anotherone In this case the current behavior, i.e. duplication, seems the most "logic" one given what written above, other solutions would be inconsistent (like moving X-Foo: bla to the always header list before applying the merge). The same example with 'setifempty' is also strange, since not setting X-Foo in the 'always' list would be incorrect, so duplication seems legitimate. As far as I can see what it is missing from the documentation is that, to be completely sure about avoiding header duplication, one should unset an header in the 'onsuccess' list before doing anything with the 'always' one, like: Header (onsuccess) unset X-Foo Header always set X-Foo somevalue Using the above the mod_proxy_http example works as expected, not duplicating any header. Any opinion from other people reading? :) -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
