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.
