Re: [squid-users] About squid ICAP implementation
Hi, Henrik From: Henrik Nordstrom <[EMAIL PROTECTED]> Subject: Re: [squid-users] About squid ICAP implementation Date: Tue, 18 Nov 2008 09:34:51 +0100 > On lör, 2008-11-15 at 05:51 +0900, Takashi Tochihara wrote: > > > I think to send "Allow: 204" & Preview: , squid must buffer not the > > whole message, but the whole *Previewed* message. (part of the message) > > "Allow: 204" is not related to previews. It tells the ICAP server that > it's OK to respond with 204 at any time, even outside of the preview. > > The preview is signalled by the "Preview: " header, and implicitly > requests the ICAP server to respond with 204 or 100 at the end of the > preview to continue the transaction or possibly a syntesised response > replacing the original message. You are right. In case of the client sends Preview & Allow: 204, the servier first responds "100 Continue" and next (as a result) responds "204 No Content", squid must buffer the whole message. I understand what you said. Thank you! best regards, -- Takashi Tochihara
Re: [squid-users] About squid ICAP implementation
On lör, 2008-11-15 at 05:51 +0900, Takashi Tochihara wrote: > I think to send "Allow: 204" & Preview: , squid must buffer not the > whole message, but the whole *Previewed* message. (part of the message) "Allow: 204" is not related to previews. It tells the ICAP server that it's OK to respond with 204 at any time, even outside of the preview. The preview is signalled by the "Preview: " header, and implicitly requests the ICAP server to respond with 204 or 100 at the end of the preview to continue the transaction or possibly a syntesised response replacing the original message. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [squid-users] About squid ICAP implementation
From: Henrik Nordstrom <[EMAIL PROTECTED]> Subject: Re: [squid-users] About squid ICAP implementation Date: Fri, 14 Nov 2008 12:11:19 +0100 > > > Allow: 204 is sent if it's known the whole message can be buffered > > > within the buffer limits (SQUID_TCP_SO_RCVBUF). It's not relaed to > > > previews. > > > > Why is there such a limitation (SQUID_TCP_SO_RCVBUF) ? > > I hope that squid always send "Allow: 204" to icap servers as much > > as possible... > > Because to send "Allow: 204" Squid must buffer the whole message. This > buffering is done in memory. Imagine what would happen if the message is > a dual layer DVD ISO image.. (6-8GB in size). I think to send "Allow: 204" & Preview: , squid must buffer not the whole message, but the whole *Previewed* message. (part of the message) tcp (or server) keeps the message, I think. e.g. squid doest not read the message (from socket), tcp keeps the message until his buffer becomes full, and when tcp buffer is full, tcp sends window size = 0 packet and then the server keeps the message... I think it is better to send Allow: 204 header, when squid sends Preview: header. (of course Preview: values needs some limitation) Do I have the wrong idea? best regrads -- Takashi Tochihara
Re: [squid-users] About squid ICAP implementation
On fre, 2008-11-14 at 15:49 +0900, Mikio Kishi wrote: > Hi, Henrik > > > Allow: 204 is sent if it's known the whole message can be buffered > > within the buffer limits (SQUID_TCP_SO_RCVBUF). It's not relaed to > > previews. > > Why is there such a limitation (SQUID_TCP_SO_RCVBUF) ? > I hope that squid always send "Allow: 204" to icap servers as much > as possible... Because to send "Allow: 204" Squid must buffer the whole message. This buffering is done in memory. Imagine what would happen if the message is a dual layer DVD ISO image.. (6-8GB in size). Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [squid-users] About squid ICAP implementation
Hi, Henrik > Allow: 204 is sent if it's known the whole message can be buffered > within the buffer limits (SQUID_TCP_SO_RCVBUF). It's not relaed to > previews. Why is there such a limitation (SQUID_TCP_SO_RCVBUF) ? I hope that squid always send "Allow: 204" to icap servers as much as possible... -- Sincerely, Mikio Kishi
Re: [squid-users] About squid ICAP implementation
Hi, Henrik >> I think it may be ACCESS_ALLOWED if currentAnswer is ACCESS_DENIED, right ? > > Hmm.. that indeed looks wrong.. > > It should be initialized to ACCESS_ALLOWED. > > And affects every access list without a default.. not just icap_access. That's right! I think so, too > Please file a bug report on this. OK!, I'll try it. >> I see. By the way, do you have any plan to support multi REQMOD icap >> servers (per request) ? > > That question is best asked on the squid-dev list. I am not currently > involved in the ICAP implementation. I see. I'll also try it. >> >> - 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) > > Right. Confused things a litte, mixing up Allow: 204 with the preview. > Been a while since I worked with ICAP. > > Allow: 204 is sent if it's known the whole message can be buffered > within the buffer limits (SQUID_TCP_SO_RCVBUF). It's not relaed to > previews. thank you! -- Sincerely, Mikio Kishi
Re: [squid-users] About squid ICAP implementation
On tor, 2008-11-13 at 05:31 +0900, Mikio Kishi wrote: > 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 ? Hmm.. that indeed looks wrong.. It should be initialized to ACCESS_ALLOWED. And affects every access list without a default.. not just icap_access. Please file a bug report on this. > I see. By the way, do you have any plan to support multi REQMOD icap > servers (per request) ? That question is best asked on the squid-dev list. I am not currently involved in the ICAP implementation. > >> - 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) Right. Confused things a litte, mixing up Allow: 204 with the preview. Been a while since I worked with ICAP. Allow: 204 is sent if it's known the whole message can be buffered within the buffer limits (SQUID_TCP_SO_RCVBUF). It's not relaed to previews. REgards Henrik signature.asc Description: This is a digitally signed message part
Re: [squid-users] About squid ICAP implementation
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
Re: [squid-users] About squid ICAP implementation
On sön, 2008-11-09 at 16:11 +0900, Mikio Kishi wrote: > Hi, would you tell me the ICAP implementation on squid. > > - 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.. > - Question.2 > Could we set "more than two" REQMOD icap servers (per request) ? Only one is supported at this stage. > - Question.3 > squid "always" sends "Allow: 204" header to icap server, right ? Yes, unless forcibly disabled by setting icap_preview_enable off. Regards Henrik signature.asc Description: This is a digitally signed message part
[squid-users] About squid ICAP implementation
Hi, would you tell me the ICAP implementation on squid. - Question.1 If there is no "icap_access" setting, The default icap access control is "allow" or "deny" ? It looks "allow"... - Question.2 Could we set "more than two" REQMOD icap servers (per request) ? - Question.3 squid "always" sends "Allow: 204" header to icap server, right ? If not, please tell me detail. - Environment squid-3.0.STABLE10 -- Sincerely, Mikio Kishi
