On 09/11/2012 01:08 AM, Eliezer Croitoru wrote:
> On 09/11/2012 01:52 AM, Amos Jeffries wrote:
>> url-rewrite, store-url,
>> and location-rewrite (also not ported) all have the same API
> This is the first time I have heard about location-rewrite and it's a
> nice and interesting interface.
> it can be helpful for cdn stuff if i got it right.
> But this is not for now.
Hm... I wonder if we are making a design mistake here by following
Squid2 steps: one helper to rewrite request URL, one helper to rewrite
store URL, then one helper to rewrite some special HTTP header, etc.
Would it be better to extend (in a backward compatible way) the URL
rewriter interface so that ONE helper can do all rewriting that is
needed (today and tomorrow)?
[ Well, you do need two helpers, one for requests and one for responses,
but you get the idea. ]
For example, a helper that knows about the enhancement may get a single
request from Squid and return something like this:
_response_lines: 2
store_uri:http://foo/....
request_uri:302:http://bar/....
and Squid would know to parse the two additional response lines and act
accordingly.
AFAICT, the primary advantage of a single URL rewriter is performance.
The primary disadvantage is some loss of flexibility: the script has to
be invoked once, without adaptation or other actions possible between
the redirector and store URL rewriter invocations, for example.
I am an ICAP/eCAP guy so I do not have much experience with URL helpers,
but I thought I would bring this up before it is too late, in case
others find it useful. The decision to go down the single-helper path
should be made now, before we add another URL rewriter.
Cheers,
Alex.
Received on Tue Sep 11 2012 - 21:53:04 MDT
This archive was generated by hypermail 2.2.0 : Wed Sep 12 2012 - 12:00:05 MDT