Sure, great. In squid3, it sounds like an eCAP module is the
appropriate way to implement this; at which point you'll still need to
implement the helper protocol, and then we'll be having the same
conversation.
In the meantime, if the internal rewrite stuff is going to go into a
2.7 release, it seems like squid can be made to address a number of
(but not all) use cases that real people are using HTTP intermediaries
for today, with very little code change, with the side effect of
making squid simpler to use (because there won't be multiple ways to
set up a helper).
I'll let your fallacy stand on its own (or not)... :)
On 09/05/2008, at 2:26 PM, Alex Rousskov wrote:
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 [EMAIL PROTECTED]
--
Mark Nottingham [EMAIL PROTECTED]
