Re: [PATCH] adaptation_meta option

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.
Received on Sat Oct 22 2011 - 01:23:46 MDT