Re: status of internal redirectors?

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 mnot@yahoo-inc.com
>>
>

--
Mark Nottingham       mnot@yahoo-inc.com