> So maybe we should simply apply the always rules > to both tables. This is the path I was going down, but I think you can only safely "edit" both tables indiscriminately due to the matching component of the action.
My first pass was adding an internal flag that suppressed the set/add/merge-like operations when "always" was looking at the r->headers_out, performing those only on err_headers_out. But this still leaves unintuitive behavior for things like merge or append, where the value is at least as likely to start in r->headers_out, but could be in neither or both tables. This is why i finally settled on the idea of changing nothing and trying to document how 'always' might need to be used to get access to some seemingly arbitrary pre-existing header values (only when you don't care about these are the directives mostly intuitive) -- Eric Covener [email protected]
