Re: [PATCH] meta_header option

On 10/12/2012 11:21 PM, Amos Jeffries wrote:
> The sensitive ones are cert, group, user and password. And we are
> constantly being asked how to pass those to ICAP anyway - so I think
> allowing them to be passed is a wanted thing and if done safely will not
> be a problem.

Agreed. Just keep in mind that we also have requests to keep them away
from ICAP (the way it is done now in Squid code and in the proposed
patch). Both preferences are valid and both should be eventually satisfied.

> Why do you not supply a configuration option to specify the particular
> notes *to* pass to an ICAP service rather than passing everything by
> default?

The current and proposed code do not pass annotations to ICAP services
by default. That is why we do not need such an option. As I have
probably mentioned earlier, adding knobs to control what gets passed and
when is far from simple and requires a dedicated project to do it right
(think different vectoring points and different services requiring
different exposure). In the proposed patch, the status quo is kept so no
additional options are required.

> Like external ACL has today, the %EXT_TAG, %LOGIN etc are not
> passed unless configured to happen. That ensures privacy and security by
> default without limiting what could be passed.

Exactly. The current and proposed annotation code also ensures privacy
and security without limiting what future code may allow admins to pass.
Such future code requires a separate project/discussion and I see no
reason to demand that those _additional_ features are added to the
current project scope because we just preserve the existing status quo
in this respect.

> I know. For ICAP where its passed in mime headers. You can choose
> whether to pass headers:
>
> Key1:value 1
> Key2:value2
>
> or headers:
>
> Squid-Note: key1="value 1", key2=value2
> Squid-Note: key3="value 3"
> Squid-Note: key4=value4
>
> ... both of which fit mime format. With the former you have your
> key:value input you seem to have been planning. With the latter you have
> the common ( key '=' value ) syntax so its parser can be re-used between
> Squid components (or the HTTP header one re-used here).

I have not thought of wrapping ICAP headers in Squid-Note by default. I
think I now understand what you meant. I do not think we should require
that.

IMO, admins should [continue to] reuse the existing ICAP header
mechanism because that is how ICAP specs pass transaction meta
information, that is how existing ICAP services send custom meta info to
Squid, and how existing Squids send custom meta info to ICAP services
(via adaptation_meta). Please note that adaptation_meta does support
Squid-Note wrapping if one wishes to use that approach -- we are not
dictating how the key:value pairs are sent to the ICAP server!

As for parser reuse, both squid.conf configuration lines and helper
responses would have key=value syntax so supporting annotations in
helper responses does not have to duplicate parser code or invent new
parsing code. And even if a new parser is needed, I think it is better
to add such a parser than to require the use of Squid-Note headers in ICAP.

Cheers,

Alex.
Received on Mon Oct 15 2012 - 16:47:13 MDT