Two very interesting changes in this draft:
"addheader" [":last"] <name: string> <value: string>
By default, the header field is inserted at the beginning of
the existing header. If the optional flag ":last" is
specified, it is appended at the end.
What's the rationale? So far (i.e., without hearing more), I liked it
better the way it was: the default being to add the header at the end,
not the beginning. I would not mind seeing a ":first" to alter that
behaviour though.
and:
A message modified by addheader or deleteheader MUST NOT
be considered the same as the original message unless it
matches the original message exactly.
For example, the following code fragment
keep;
addheader "X-Flavor: vanilla"
keep;
files two messages, not one.
I see where that is coming from. If you do a "keep" after changing
the header, it's assumed that you really meant it; and if weeding out
duplicate "keep" operations prevents that, then you have lost some
change. However: you have not lost the message unless some prior
action had deliberately caused it; any weeding out represents a script
error rather than loss of the message, so I am not sure this is an
improvement.
On the flip side, anyone who has depended on duplicate "keep"
operations being weeded out will be surprised by having two messages
filed. Likely if you have done a "keep" in the same code area as the
addheader, you probably do want the second copy. But in another
case? Not so clear, especially if you have done something else with
the message after changing the header.
One alternative: make a note that the message has changed, and if so,
inhibit any subsequent de-duplication logic on the next action only.
So the next "keep" would succeed unless (e.g.) "redirect" were done
first. This would introduce a new "changed" flag, but this new text
introduces that concept anyway. That's not as perfect as, say, views,
but it's no worse than the suggested one.
BTW, in the absence of a "changed" flag, this new philosophy might also
imply that implicit keep is once again turned on (if it had been
turned off). Whether it is or is not is now ambiguous.
And.. what about replaceheader? I would assume that any change made
by replaceheader would also cause the message to be considered
"different" -- but that new text explicitly calls out "editheader" and
"deleteheader" without mentioning "replaceheader," so it seems
deliberate.
Yours,
mm