On 10/21/2011 07:03 PM, Amos Jeffries wrote: > Can we limit it to not overwriting or adding standard headers? rather > than just warning. > Adding custom headers and ones needed for future protocol extensions is > all fine and well. But wrongly adding central protocol headers midway > down a chain is an attractive trap newbie admin are always asking about > how to do, even if though breaks the final result.
We can prohibit them, but there are probably cases where the conflict cannot be accurately determined until the transaction time. For example, the admin may want to supply standard ICAP headers NOT generated by Squid for this particular transaction (because Squid guessed wrong that they are not needed). The next step after the current warning is probably to prohibit conflicts at runtime, if admin-supplied meta-headers for a given transaction are about to conflict with Squid-added meta headers. In those cases, Squid should win and issue a [once-per-header] warning. The next next step would then be to make the behavior configurable and allow the admin to consciously complement and/or overwrite Squid headers. Again, this could be useful for headers where Squid has to guess whether to send them or not (or what values to use). For now, I think the warning is slightly better than the prohibition, mostly because we warn at configuration time but conflicts may or may not happen at transaction time. Newbies should pay attention to warnings :-). I do not have a strong opinion here though. Anything you and Christos agree on is fine with me. Thank you, Alex.
