Search squid archive

Re: Re: Redirector idea using request header

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux