Cache buster on self host DTM library

[jeremyl59043873]

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

[jantzen_b]

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]

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

[jeremyl59043873]

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]

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.

[jeremyl59043873]

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]

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.