>> 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.
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.
>> >
>
Received on Tue Dec 02 2008 - 15:23:52 MST
This archive was generated by hypermail 2.2.0 : Wed Dec 03 2008 - 12:00:03 MST