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.
