Re: [squid-users] About squid ICAP implementation

From: Mikio Kishi <mkishi_at_104.net>
Date: Thu, 13 Nov 2008 05:31:53 +0900

Hi, Henrik

Thank you for your reply.

>> - Question.1
>> If there is no "icap_access" setting,
>> The default icap access control is "allow" or "deny" ?
>> It looks "allow"...
>
> Should be deny.. icap_access selects which icap class to forward the
> request via, and without any icap_access directive there is no selected
> icap class..

hmmm, however it looks "allow"....

In ACLChecklist.cc#check()

> 128 /* deny if no rules present */
> 129 currentAnswer(ACCESS_DENIED);
> ..........
> 188
> 189 checkCallback(currentAnswer() != ACCESS_DENIED ? ACCESS_DENIED : ACCESS_ALLOWED);

I think it may be ACCESS_ALLOWED if currentAnswer is ACCESS_DENIED, right ?

>> - Question.2
>> Could we set "more than two" REQMOD icap servers (per request) ?
>
> Only one is supported at this stage.

I see. By the way, do you have any plan to support multi REQMOD icap
servers (per request) ?

>> - Question.3
>> squid "always" sends "Allow: 204" header to icap server, right ?
>
> Yes, unless forcibly disabled by setting icap_preview_enable off.

But, it looks more complex condition.... (checking virginBody)

In ICAP/ICAPModXact.cc

> 1266 // decides whether to allow 204 responses
> 1267 bool ICAPModXact::shouldAllow204()
> 1268 {
> 1269 if (!service().allows204())
> 1270 return false;
> 1271
> 1272 return canBackupEverything();
> 1273 }
> 1274
> 1275 // used by shouldAllow204 and decideOnRetries
> 1276 bool ICAPModXact::canBackupEverything() const
> 1277 {
> 1278 if (!virginBody.expected())
> 1279 return true; // no body means no problems with backup
> 1280
> 1281 // if there is a body, check whether we can backup it all
> 1282
> 1283 if (!virginBody.knownSize())
> 1284 return false;
> 1285
> 1286 // or should we have a different backup limit?
> 1287 // note that '<' allows for 0-termination of the "full" backup buffer
> 1288 return virginBody.size() < TheBackupLimit;
> 1289 }

--
Sincerely,
Mikio Kishi
Received on Wed Nov 12 2008 - 20:31:56 MST

This archive was generated by hypermail 2.2.0 : Thu Nov 13 2008 - 12:00:03 MST