On 07.05.2012 03:48, gslavic wrote:
First thing, thanks for the idea Marcus.
For redirecting requests to different sites that would be the
solution,
unfortunately ICAP is not the solution that will work for my problem.
Problem is that level of processing required after getting the
request
header, interserver communication Squid-ICAP and other problems that
would
arise from them will put too much new problems on already bug-rich
environment work in :-( Plus, involving another server in already
request/bandwidth/workload interface I am developing is bound to
generate
series delays and problems.
I think you may need to redesign your environment a little. ICAP was
explicitly created to simplify overly-complex environments and HTTP
request manipulation such as you are describing. Have a read through the
rest of this email and contemplate the last paragraph before continuing.
Also;
eCAP has a lighter interface and modules are loaded directly by Squid.
eCAP modules can also be loaded into an ICAP server for use via ICAP
if that way is needed later for some reason.
Another problem is that the my redirector script is the starting
point of
other programs that not only redirect/rewrite URI but do serious work
on the
future destination (local Apache server) that the client will be
redirected
to :-)
That is where you are going wrong. The re-writer API to Squid is
designed specifically and *solely* to redirect or re-write URLs. Not to
do other changes on the request. The re-write portion of it is a major
hack which violates HTTP specifications in a big way and should be
avoided as much as possible. It pre-dates and has been superseded by the
ICAP protocol.
Only thing that will work for my problem is a system variable, or
modification of redirector interface that will deliver the HTTP_GET
request
header to Perl redirector script. Besides, just like ICAP, Squid gets
the
request header, it memorizes it in SOME program variable (otherwise
it would
be impossible for Squid to write it in access.log AFTER it handles
the
request). Only thing that I need, is for somebody to help me find
out:
1. Where is that variable ?
URL re-writer:
* Squid sends a URL and specific narrow set of client TCP details to
the url_rewrite interface
* receives back either a non-change (empty line) or a formatted string
of key-pairs.
* builds a whole new HTTP request merging the client original HTTP
request state and the URL received back from the re-writer.
* fetches the new HTTP request as if it was the one received directly
from the client.
Compare this to ICAP/eCAP:
* Squid sends the HTTP request plus headers to the *CAP interface
* receives back either a non-change *CAP response or a new/updated set
of HTTP request headers.
* builds a new HTTP request from the details received back from the
*CAP response.
* fetches the new HTTP request as if it was the one received directly
from the client.
So as you can see what you are proposing is to turn the URL-rewriter
interface into an ICAP interface.
+ ICAP was designed explicitly for HTTP request/response adaptation
such as your are asking for
+ works with *any* proxy, not just Squid.
+ removes the need for complex Squid URL-rewrite helpers entirely
+++ our perl script can *be* an "ICAP server" easily It just needs to
add/remove the ICAP protocol header wrappers from around the HTTP
headers passed in. That way you avoid any need for re-writer helpers and
push all the complexity into a single, more compact and efficient
adaptation service.
Amos
