Admin UI: Lookup URI vs Regex Lookup

[Mark Moseley <mo...@gmail.com>]

(ATS 4.1.1, Ubuntu Precise 64-bit)

Hi. Was looking into cache invalidation and noticed an oddity that I'm
hoping can be worked around.

I'm making use of remapping in such a way that the remapped URL no longer
has any domain-identifying information in it (since it's still in the Host:
header). The new remapped domain is based on the incoming IP address,
munged into a hostname. All this is working just fine, so no problem with
the cache itself.

If I use the Admin UI and go to "Lookup url" or "Delete url", I can use the
pre-mapped URL with those and they can pull up information (or delete from
the cache) as I'd expect. There will eventually be many thousands of
domains coming in, with completely unrelated content, i.e. overlapping URIs.

However for the "Regex lookup / delete / invalidate", I seem to be only
able to use the post-remapped URL, which in my case is sort of useless. So
if I do a "Regex lookup" for ".*",

Is there a setting I'm missing that can change that behavior? Or is that
not actually the expected behavior?

My main concern is a customer wanting to invalidate all the content in the
cache for their domain. But if I can't differentiate purely by URL, then I
basically have to invalidate the entire cache to accomplish invalidating
for everything under a single domain (or in my case, everything using the
same destination IP address, which could be tens of thousands of different
domains).

I know I'm probably a corner case (most remapped domains are probably more
uniquely derived from the original domain) but I imagine it'd be useful for
most people to be able to operate on the pre-remapped domains, even in more
general cases.

Thanks!

Re: Admin UI: Lookup URI vs Regex Lookup

["Harris, Scott" <Sc...@sensis.com.au>]

It been a while since I logged the issue but from memory I think the pristine host header setting (can not remember which way) causes it to break.

Scott





-------- Original message --------
From: Mark Moseley <mo...@gmail.com>
Date:
To: users@trafficserver.apache.org
Subject: Re: Admin UI: Lookup URI vs Regex Lookup


On Fri, Nov 29, 2013 at 11:34 AM, Mark Moseley <mo...@gmail.com>> wrote:
(ATS 4.1.1, Ubuntu Precise 64-bit)

Hi. Was looking into cache invalidation and noticed an oddity that I'm hoping can be worked around.

I'm making use of remapping in such a way that the remapped URL no longer has any domain-identifying information in it (since it's still in the Host: header). The new remapped domain is based on the incoming IP address, munged into a hostname. All this is working just fine, so no problem with the cache itself.

If I use the Admin UI and go to "Lookup url" or "Delete url", I can use the pre-mapped URL with those and they can pull up information (or delete from the cache) as I'd expect. There will eventually be many thousands of domains coming in, with completely unrelated content, i.e. overlapping URIs.

However for the "Regex lookup / delete / invalidate", I seem to be only able to use the post-remapped URL, which in my case is sort of useless. So if I do a "Regex lookup" for ".*",

Is there a setting I'm missing that can change that behavior? Or is that not actually the expected behavior?

My main concern is a customer wanting to invalidate all the content in the cache for their domain. But if I can't differentiate purely by URL, then I basically have to invalidate the entire cache to accomplish invalidating for everything under a single domain (or in my case, everything using the same destination IP address, which could be tens of thousands of different domains).

I know I'm probably a corner case (most remapped domains are probably more uniquely derived from the original domain) but I imagine it'd be useful for most people to be able to operate on the pre-remapped domains, even in more general cases.


Hmm, just came upon https://issues.apache.org/jira/browse/TS-1767 so I guess it's a known thing.

Is fixing it still on the roadmap for 4.2.0? Or does the last entry mean it's been pushed back to 5.0.0?

Re: Admin UI: Lookup URI vs Regex Lookup

[Mark Moseley <mo...@gmail.com>]

On Fri, Nov 29, 2013 at 11:34 AM, Mark Moseley <mo...@gmail.com>wrote:

> (ATS 4.1.1, Ubuntu Precise 64-bit)
>
> Hi. Was looking into cache invalidation and noticed an oddity that I'm
> hoping can be worked around.
>
> I'm making use of remapping in such a way that the remapped URL no longer
> has any domain-identifying information in it (since it's still in the Host:
> header). The new remapped domain is based on the incoming IP address,
> munged into a hostname. All this is working just fine, so no problem with
> the cache itself.
>
> If I use the Admin UI and go to "Lookup url" or "Delete url", I can use
> the pre-mapped URL with those and they can pull up information (or delete
> from the cache) as I'd expect. There will eventually be many thousands of
> domains coming in, with completely unrelated content, i.e. overlapping URIs.
>
> However for the "Regex lookup / delete / invalidate", I seem to be only
> able to use the post-remapped URL, which in my case is sort of useless. So
> if I do a "Regex lookup" for ".*",
>
> Is there a setting I'm missing that can change that behavior? Or is that
> not actually the expected behavior?
>
> My main concern is a customer wanting to invalidate all the content in the
> cache for their domain. But if I can't differentiate purely by URL, then I
> basically have to invalidate the entire cache to accomplish invalidating
> for everything under a single domain (or in my case, everything using the
> same destination IP address, which could be tens of thousands of different
> domains).
>
> I know I'm probably a corner case (most remapped domains are probably more
> uniquely derived from the original domain) but I imagine it'd be useful for
> most people to be able to operate on the pre-remapped domains, even in more
> general cases.
>


Hmm, just came upon https://issues.apache.org/jira/browse/TS-1767 so I
guess it's a known thing.

Is fixing it still on the roadmap for 4.2.0? Or does the last entry mean
it's been pushed back to 5.0.0?