Re: bug 1208: internal redirect

From: Amos Jeffries <squid3@dont-contact.us>
Date: Fri, 18 Jan 2008 12:15:20 +1300 (NZDT)

> To update the patch for this feature, I have some comments regarding
> hno@'s
> comment #5:
>
>> 1. URL escaping is already provided by rfc1738_encode().
>
> I'll follow your advise.
>
>> 2. I would prefer redoing the core access controls to return other
>> entities than
>> allow/deny to make things like this patch considerably cleaner. There is
>> now
>> quite many acl driven directives selecting various things, and all need
>> special
>> code today..
>>
>> tcp_outgoing_xxx
>> access_log
>> reply_body_max_size
>> always/never_direct could be joined into one if this was available
>
> Should follow this for updating 'internal redirect'?
>
> Perhaps that's easier with squid3 async framework, and would involve quite
> many
> changes on squid2.
>
> Let me know your opinion.

It's a design architecture issue in squid. As you point out its a major
change. The core dev team are still arguing over architectural issues so
its not something we want to make any decisions on just yet.

IMHO, it should have another bug # or wiki Features entry and not be
involved with #1208 directly.

As for 1208, I have been turning that concept over in my head for a long
while now.
What I have come up with is what I'd term a mapping rather than a redirect
with the syntax:
  'map_domain' fqdn1 fqdn2 [ fqdn2 ...] [deny acl [...]]
- anything that dstdomain matches a fqdn2* gets its dstdomain mapped to
the given fqdn1. fqdn2 can be a wildcard just as in ACL.

  'map_url' url1 url2 [url2 ...] [deny acl [...]]
- anything that matches a url2* prefix gets that prefix replaced by url1
- acl can be used to block this behaviour for any request

This plays nicely in with redirection and Adrians latest storage
manipulator. As it can be done at the point of input and replace both with
a single mapping.

How close it that to your new version of the patch?

Amos
Received on Thu Jan 17 2008 - 16:15:33 MST

This archive was generated by hypermail pre-2.1.9 : Wed Jan 30 2008 - 12:00:09 MST