trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harris, Scott" <>
Subject Re: Admin UI: Lookup URI vs Regex Lookup
Date Fri, 29 Nov 2013 21:16:37 GMT
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.


-------- Original message --------
From: Mark Moseley <>
Subject: Re: Admin UI: Lookup URI vs Regex Lookup

On Fri, Nov 29, 2013 at 11:34 AM, Mark Moseley <<>>
(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

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

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 so I guess it's a known

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?

View raw message