Found open issue https://issues.apache.org/jira/browse/TS-1767 that describes exactly this case.


On Thu, May 15, 2014 at 1:38 PM, Acácio Centeno <acacio.centeno@azion.com> wrote:
Hello,

I work on the same team as Daniel, and this was what I observed. Using pristine_host_hdr set to 1 the original URL is indeed used as cache key (I'm calling the original URL the one the client sends). Therefore, if we do a cache lookup or delete using the original URL, the object is found.

However, if we do a _regex_ lookup/delete using the original URL, then it's not found.

I read the code for the regex procedures (ShowCache::
handleCacheScanCallback) and found out that it will read every object in the cache, and for each one it will print its URL to a buffer, then comparing this buffer with the informed regex. To build this buffer, the code gets a pointer to a HTTPHdr object, and if it has the field m_target_in_url set to true, the code will not consider the Host header. It turns out that in our tests, the object does have this field set, because the request being sent to the origin has this format:

GET http://<remapped_domain><URI> HTTP/1.1
...
Host: <original_domain>
...

That is, the GET line has the remapped URL, instead of just the URI or the original URL.

Therefore, using the remapped domain, the regex procedure does not match the expression we're sending to it, as our expression uses the original domain.

Is there a configuration we could do to force ATS to send just the URI on the GET line? I think that if such a config exists, we would get the behavior we were expecting, as the UrlPrintHack ctor does consider the Host header if m_target_in_url is not set.

If such a configuration does not exist, do you think it would be the case to patch the URL building done by UrlPrintHack to check if pristine_host_hdr is set and, if so, build the URL using the Host header instead of the one in the GET line?

Thanks,
Acácio.


On Wed, May 14, 2014 at 6:16 PM, Leif Hedstrom <zwoop@apache.org> wrote:

On May 13, 2014, at 12:14 PM, Daniel Biazus <daniel.biazus@azion.com> wrote:

Hi Guys,

    We've been using traffic server as a reverse proxy to delivery static content across multiple CDN nodes, though the regex purge works as expected through web UI tool, We've been facing some challenges regarding the cache keys when the objects are stored in cache.
    In order to have a better understanding of our scenario, let's take a look at this example:

Scenario 1:

- traffic server is working as a reverse proxy:

#remap.config


- We have to purge all css files under the URL http://finalurl.foo.bar/

Considering this, we have to purge the following regex:

    
The example above doesn't work due the fact that traffic server uses the origin URL to calculate the hash key, then, in this case we have to make a purge request using the origin server URL (that's not nice with our clients, right ?):


So guys, anyone knows if there is a way to change the hash key in traffic server, or even if is there some workaround to deal with this scenario ?


The common way of doing this is to have a plugin, that generates cache keys based on a combination of the URL and a generation ID. This would easily be configurable per remap rule, such that you can then instantly (O(1)) purge all objects for that remap rule simply by modifying (increasing) the generation ID. There is one such plugin in the public domain, although it probably needs a little loving. :) An easy adoption to that plugin would be to take the generation ID as an argument on the remap rule.

— Leif




--

Acácio Centeno


Porto Alegre, Brasil + 55 51 3012 3005 
Miami, USA + 1 305 704 8816 

Quaisquer informações contidas neste e-mail e anexos podem ser confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer forma de utilização deste documento depende de autorização do emissor, sujeito as penalidades cabíveis.

Any information in this e-mail and attachments may be confidential and privileged, protected by legal confidentiality. The use of this document require authorization by the issuer, subject to penalties.




--

Acácio Centeno


Porto Alegre, Brasil + 55 51 3012 3005 
Miami, USA + 1 305 704 8816 

Quaisquer informações contidas neste e-mail e anexos podem ser confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer forma de utilização deste documento depende de autorização do emissor, sujeito as penalidades cabíveis.

Any information in this e-mail and attachments may be confidential and privileged, protected by legal confidentiality. The use of this document require authorization by the issuer, subject to penalties.