Re: status of internal redirectors?

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Thu, 08 May 2008 22:26:33 -0600

On Fri, 2008-05-09 at 10:09 +1000, Mark Nottingham wrote:
> I was talking about the rewriters / redirector, actually.
>
> Given that the helper interface is easy to understand and widely used,
> whereas eCAP essentially requires writing a squid plug-in, I can't
> agree, Alex. This isn't a big change at all, and the jump from a
> rewriter to eCAP is a big one.

Not if there is an eCAP module that supports the helper interface.

> Note that I'm *not* talking about using helpers to rewrite headers or
> similar; all I want to be able to do is to adjust what the input to
> the helper is, so that it can make rewrite decisions on things other
> than client_ip, url, method. E.g., rewriting based upon a cookie.

Yes, I am using the slippery slope argument. The person before you asked
for Squid port value. You ask for headers. The next person asks for the
first 10 bytes of the body (to determine the true message type), and the
third person complains that the redirector failures are not bypassed or
that the redirectors are not chained.

Alex.

> On 09/05/2008, at 8:01 AM, Alex Rousskov wrote:
>
> > On Thu, 2008-05-08 at 23:19 +0200, Henrik Nordstrom wrote:
> >> On tor, 2008-05-08 at 08:35 -0600, Alex Rousskov wrote:
> >>
> >>> I am not sure this is the same topic, but I have already raised
> >>> doubts
> >>> (on the wiki and in the bug report) that we should extend the
> >>> Squid-specific helper interface significantly beyond its current
> >>> relatively simple state. I still believe it is worth discussing
> >>> whether
> >>> more complex uses should be routed through ICAP or eCAP instead of
> >>> slowly inventing yet another complicated and poorly maintained
> >>> traffic
> >>> adaptation interface.
> >>
> >> I think Mark is talking about the store url rewriter. It's a cache
> >> maintenance function, not really modifying the request/response in
> >> any
> >> manner, and I don't see how to fit that in ICAP or even the goals of
> >> eCAP.
> >>
> >> But it's possible eCAP may grow in future to include such things..
> >
> > Agreed on all counts: store rewriting does not fit ICAP or current
> > eCAP
> > scope well, but eCAP scope may change. My comment still applies, I
> > think. ICAP and especially eCAP do not really care what the vectoring
> > point is. They just "rewrite" messages that we feed them with. The
> > purpose of that rewrite (in a broad sense) can be a cached URL
> > maintenance function, for example.
> >
> > Alex.
> >
> >
>
> --
> Mark Nottingham mnot@yahoo-inc.com
>
Received on Fri May 09 2008 - 04:28:21 MDT

This archive was generated by hypermail 2.2.0 : Tue May 13 2008 - 12:00:04 MDT