[RFC] One helper to rewrite them all

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Tue, 11 Sep 2012 15:52:49 -0600

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