trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Acácio Centeno <acacio.cent...@azion.com>
Subject Re: traffic server cache key
Date Thu, 15 May 2014 16:38:26 GMT
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
>
> map http://finalurl.foo.bar/   http://originserver.foo.bar/
> reverse_map  http://originserver.foo.bar/  http://finalurl.foo.bar/
>
> - We have to purge all css files under the URL http://finalurl.foo.bar/
>
> Considering this, we have to purge the following regex:
>
> - http://finalurl.foo.bar/*.css
>
> 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 ?):
>
> - http://originserver.foo.bar/*.css
>
> 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.

Mime
View raw message