Re: bug 1208: internal redirect

From: Gonzalo Arana <gonzalo.arana@dont-contact.us>
Date: Fri, 18 Jan 2008 09:34:12 -0200

On Jan 17, 2008 9:15 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>
> <snip>
>
> 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.

This can be achieved with my proposed internal redirect scheme:
acl old_domains dstdomain old.domains.here
acl old_domains dstdomain .fancier.domain
redirect http://your.new.domain/%rp old_domains

> '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

I see. To fit my needs, I require url1 to interpolate tags like %et ('tag
returned from external acl'). But, with map_url scheme, as we would be
replacing prefixes, it would not make sense to interpolate those tags
They should also be available on suffixes (or in the middle).

I understand the need for map_url scheme. I would rather not add
another url-mapping directive, since it would not be clear which directive
get processed first (something like never_direct, always_direct,
cache_peer_access, and so on).

So, we could adapt redirect directive to a syntax like this:

redirect replace http://the.new.url/to?replace=%ue acl1 !acl2 acl3
redirect prefix http://some.prefix/to/replace
http://prefixes.to/be/replaced http://another.prefix/blah

Having a directive with hibrid syntax is not wise neither I guess, but
this is what comes to my mind to accomodate all suggested needs.

On the other hand, this approach:
1) it is quite clear the order of the directive processing.
2) we have the possibility for further extending the redirect
directive with other second level directives
(we would have 'replace' and 'prefix' for the moment).

Amos, does this satisfy your needs/thoughts?

> 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.

I plugged it into the very same stage of external redirectos. Should this be
merged with store_rewrite? If that's the case, it would take me longer.

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

Quite close I think (a memory corruption issue, most likely). Stay tuned.

Regards,

-- 
Gonzalo A. Arana
Received on Fri Jan 18 2008 - 04:34:16 MST

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