Level 3

Solved

Cache buster on self host DTM library

Forum|Forum|8 years ago
October 6, 2017
6 replies
4329 views

Hi Adobe Team -

I am using the self hosting solution and the DTM file still has a random number generated at the end of the script

for example (obfuscated for security):

Domain.com/adobe/0895ff6db5a050db81bxxxxxx/satelliteLib-f80d620286957e28c3f38cccccc.js?_=1507318425564

can you please advise on why this cache busting is still happening even though we are hosting the file ourselves?

& how to turn off auto cache busting?

Jeremy

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by jantzen_b

I'm sure Amazon does have some version of cache control since all CND's should, but I'm not familiar with it. From the DTM perspective, we don't add a random number as a query string to the end of our files as a cache buster.

You may need to check with whoever setup the retrieve of your DTM library (file download or FTP setup). They may have some sort of script that retrieves the file from us, adds the random number, then deploys to your web server.

jantzen_b

Adobe Employee

Hi Jeremy,

I've branched your question off into it's own thread since the original thread is already answered and this is it's own question.

Cheers,
Jantzen

jantzen_b

Adobe Employee

Jeremy,

DTM itself, doesn't contain any cache busting technologies that I'm aware of. Typically, customers will use Akamai hosting which has its own version of cache control. Are you sure there is nothing on your side that is appending the random number at the end of the script file?

Thanks,
Jantzen

J

jeremyl59043873Author

Level 3

I have had my front end dev team review the need to 'cache' the adobe file and upon their initial review they are scratching their heads as to why this random number is being set. So it's not something they are doing on purpose.

we're loading the DTM file into a single page app (from our server) and we're not able to 'embed' them because that would require us to embed both Sit and Prod versions of the DTM JS file into the HTML given our deployment processes. Would this be a potential root cause of what we're seeing?

We are also hosting our site on Amazon Web Services. You mentioned that Akamai has it's own version of cache control. Are you aware of any such cache control solution with AWS (just curious, it's okay if you don't as you're not amazon)?

we are taking another look at this internally with the front end dev team next week but thought I'd reach out to explore potential causes and solutions.

jantzen_b

Accepted solution

Adobe Employee

I'm sure Amazon does have some version of cache control since all CND's should, but I'm not familiar with it. From the DTM perspective, we don't add a random number as a query string to the end of our files as a cache buster.

You may need to check with whoever setup the retrieve of your DTM library (file download or FTP setup). They may have some sort of script that retrieves the file from us, adds the random number, then deploys to your web server.

J

jeremyl59043873Author

Level 3

Hello -

we've been using the file share FTP solution for almost 3 years without issue (caching worked just fine). I've been able to verify that our non-aws deployment servers are NOT cache busting.

it wasn't until we started moving towards AWS that we started to experience this issue of cache busting. So it seem pretty clear the issue is AWS related.

I appreciate your time, and I consider this question answered. Thanks so much

jantzen_b

Adobe Employee

I'm glad you were able to narrow down the problem. Best of luck in solving the remaining portion. I'll mark this as resolved.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded