Duplicate of bug 6092 and bug 6208.

In particular, bug 6092 comment 3 (difference between empty and non-existent header) and bug 6208 comment 1 are noteworthy.

*** This bug has been marked as a duplicate of bug 6092 ***

6092 is about changing behavior of add_header unconditionally.
6692 is about providing user with option to change behavior in SOME cases by supporting new add_header_cond.

It is about leaving user the choice.

(In reply to comment #2)
> 6092 is about changing behavior of add_header unconditionally.
> 6692 is about providing user with option to change behavior in SOME cases by
> supporting new add_header_cond.

Well then...

So there are two Template Tags in your proposed new option. One being the conditional to test for emptiness, one being the actual header's value.

This seems slightly redundant, unless specifically intended to also support weird edge cases:

(a) Adding a header with a value of _BAR_ based on the template tag expansion
    of _FOO_.

    add_header_cond all _FOO_ _BAR_

    In particluar this scenario can result in seriously confusing header's
    added, and even in adding an empty header.

(b) Additionally add static text to the header's value.

    add_header_cond all _FOO_ "This header's value is _FOO_"


Unless one these really is desired, I'd propose to drop the condition and add the header based on it's value being empty or not.

  add_header_cond all Languages _LANGUAGES_


An alternative would be, to implement an option to remove headers if empty.

  add_header  all Languages _LANGUAGES_
  hack_header all Languages

The first option is the traditional, unconditional add_header, or possibly the default as with the Level header. The second marks the header for suppression, if empty. This also works out of the box with stock headers, without resorting to the remove_header option.

I can offer a hack-ish proof-of-concept implementation (hence the option's name) for this concept, which I wrote quite a while ago. Probably needs re-view, though, haven't used it in a while.

(In reply to comment #3)
>     add_header_cond all _FOO_ _BAR_

Ah, the "languages" repetition in the original example! Forgot the header name, should have been

      add_header_cond all HeaderName _FOO_ _BAR_

Same with (b) of course.


> An alternative would be, to implement an option to remove headers if empty.
> 
>   add_header  all Languages _LANGUAGES_
>   hack_header all Languages
> 
> The first option is the traditional, unconditional add_header, or possibly the
> default as with the Level header. The second marks the header for suppression,
> if empty. This also works out of the box with stock headers, without resorting
> to the remove_header option.

And also can be used to specify a different type for conditional removal, if desired, like "ham" or "spam" even if the stock header is added to "all".

Case 3a and 3b)
think about add_header_cond all _FOO_ text1 _FOO_ text2 _FOO_1_ text3 _FOO_1_

I suggested syntaxt intendedfor "set of tags" where  _FOO_1_ and i_FOO_2_ are expected to be set only when _FOO_ is set

(In reply to comment #5)
> Case 3a and 3b)

I don't understand where you're heading at. Please clarify that use case with correct, matching Template Tags and a more verbose explanation.

Anyway, that most likely is too complicated, and hard to parse, if there may be spaces and quoted strings. With the add_header syntax as-is, the Template Tags are nothing else than a string (without spaces, so no quotes required). Template Tags may, however, be part of a quoted string...