> > >> Moshe Beeri wrote:
> > >> > Hi,
> > >> >
> > >> > I am trying to add extension to ICAP layer in squid 3.0 STABLE
> 10.
> > >> > Our service works both in respmod and reqmod, in some cases we
> > know
> > >> > right after reqmod that the data should passed directly to the
> > >> client.
> > >> > in those cases we like to be more efficient by not utilizing
> > respmod
> > >> at
> > >> > all, sending the server's response directly to the client,
> > bypassing
> > >> > ICAP server's respmod.
> > >> >
> > >> > Does any one have an idea how to decided after 'reqmod reply'
> > >> > whether http server response will be sent to ICAP server's
> respmod
> > > or
> > >> to
> > >> > send directly to client?
> > >> > Any suggestions how to trick the mechanism?
> > >>
> > >> You can add a header to the http request during reqmod processing
> eg
> > >> "X-ICAP-Respmod-Needed: False" and play with a squid req_header
> acl
> > > to
> > >> allow/deny respmod processing:
> > >>
> > >> acl AnXIcapHeader req_header X-ICAP-Respmod-Needed False
> > >> icap_access class_respmod deny AnXIcapHeader
> > >>
> > >> Regards,
> > >> Christos
> > >>
> > > Thanks Christos,
> > >
> > > Your solution, thought elegant, is not secure since the web server
> > might
> > > change the parameter and cause unsafe data transfer to client.
> > > can I utilize acl to do the same by adding header to ICAP (reqmod)
> > > response?
> >
> > No the web server can not change the parameter:
> > - During the ReqMod ICAP request you are modifying the http request
> > adding an extra header (the X-ICAP-Respmod-Needed or any other you
> > want)
> > - Squid will use the modified (by your ICAP server) requests when
> > going
> > to evaluate the AnXIcapHeader acl. The http server can not modify
> the
> > http request.
>
> Hi Christos,
>
> First I would like to thank you for you response it is really
> appreciated.
> You are right the web server can not change the request,
> but it can utilize the data to trick out filter.
> We also would like to keep the changes in the scope between
> the Squid and the ICAP server and not "pollutes" the traffic
> that goes out to the Internet.
>
> In the worst case scenario we will use your acl solution,
> but we prefer to add those capabilities into squid 3.0 source, and to
> benefit the community as well.
>
> Regards,
> Moshe Beeri.
>
Hi Christos,
I found the right place to make this efficient change.
ServerStateData::adaptOrFinalizeReply()
{
#if ICAP_CLIENT
if (TheICAPConfig.onoff) {
//start
if(request->bypass_respmod) {
setFinalReply(virginReply());
return;
}
//end
ICAPAccessCheck *icap_access_check =
new ICAPAccessCheck(ICAP::methodRespmod,
ICAP::pointPreCache,
request, virginReply(), icapAclCheckDoneWrapper, this);
icapAccessCheckPending = true;
icap_access_check->check(); // will eventually delete self
return;
}
#endif
setFinalReply(virginReply());
}
Regards,
Moshe Beeri,
> >
> > Regards,
> > Christos
> >
> > >
> > > In 2.5 I changed the code using fde object associated with
> client_fd
> > to
> > > pass context information from reqmod to respmod, disabling ICAP by
> > > returning a constant instead of icap_writer, but with 3.0 code
> > > improvement this hock has gone or I am missing it, is there any
why
> > to
> > > do it in 3.0 ?
> > >
> > > Regards,
> > > Moshe.
> > >> >
> > >> > Thanks Allot,
> > >> > Moshe Beeri.
> > >> >
> > >
> >
