<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Joachim,<div class=""><br class=""></div><div class="">I recognize the problem when dealing with loading javascript resources, but not for Seaside-rendered javascript.</div><div class="">I find the latter a bit strange since that gets injected in a load script or a script tag, and that cannot be cached unless your entire page is cached.</div><div class=""><br class=""></div><div class="">So, when referencing javascript sources external to the Seaside image, this is what we do to ensure a browser does not use a cached version: <a href="https://stackoverflow.com/questions/9692665/cache-busting-via-params" class="">https://stackoverflow.com/questions/9692665/cache-busting-via-params</a></div><div class="">In summary:</div><div class="">- add a query parameter to the url of the javascript resource (i.e. behind the ‘?’ character)</div><div class="">- use some version string in the code base as value in that query parameter such that it is different from the value in the current previous production version (using a version number is most intuitive).</div><div class=""><br class=""></div><div class="">Here is the implementation for that in Seaside:</div><div class=""><br class=""></div><div class="">updateRoot: aRoot</div><div class=""><span class="Apple-tab-span" style="white-space:pre">  </span>…</div><div class=""><span class="Apple-tab-span" style="white-space:pre">       </span>aRoot javascript resourceUrl: '/js-libs/jquery.dataTables.min.js' version: resourceVersion.</div><div class=""><span class="Apple-tab-span" style="white-space:pre">       </span>…</div><div class=""><br class=""></div><div class="">with the implementation of resourceUrl:version: is:</div><div class=""><br class=""></div><div class=""><div class="">WAContentElement>>resourceUrl: aString  version: versionString</div><div class=""><span class="Apple-tab-span" style="white-space:pre">   </span>"Concatenates a version string to the resource url. </div><div class=""><span class="Apple-tab-span" style="white-space:pre">    </span>The version string is put in the GET request's variables list and ignored by the webserver.</div><div class=""><span class="Apple-tab-span" style="white-space:pre">       </span>Changing the version string can trigger a browser cache refresh when needed."</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>self url: ((canvas absoluteUrlForResource: aString) addField: versionString)</div></div><div class=""><br class=""></div><div class="">Now, I am puzzled by the resources that are cached for generated javascript… can you share some more code on how that is included in your webpage?</div><div class=""><br class=""></div><div class="">cheers,</div><div class="">Johan</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 11 Sep 2017, at 08:41, <a href="mailto:jtuchel@objektfabrik.de" class="">jtuchel@objektfabrik.de</a> wrote:</div><br class="Apple-interchange-newline"><div class="">
  

    <meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class=""><p class="">Hi there,</p><p class=""><br class="">
    </p><p class="">this may seem like a stupid question, but it seems I am
      struggling with the Browsers' cache handling of Javascript Code.</p><p class="">Let me start by describing what happens: I change some javascript
      code in my Seaside app, deploy it onto the server and restart the
      image.</p><p class="">For many (but not all) users, the changes don't get downloaded
      for days. They need to go to a page, press the Browser's reload
      button and from then on they are fine. This is both good to know
      and bad at the same time for several reasons:</p>
    <ul class="">
      <li class="">some users never call and are frustrated</li>
      <li class="">the number of support cases causes high cost</li>
    </ul><p class="">The effect shows up both for Javascript that gets served from the
      file system (using rewrite rules) and for code served directly
      from Seaside in the render* methods. <br class="">
    </p><p class="">For the file system stuff, we have to work on the caching
      settings on Apache. But I am really helpless in case of "freshly
      rendered" JavaScript code. How could that even be cached by a
      Browser???<br class="">
    </p><p class=""><br class="">
    </p><p class="">Any hints are welcome</p><p class=""><br class="">
    </p><p class="">Joachim<br class="">
    </p><p class=""><br class="">
    </p><p class=""><br class="">
    </p>
    <br class="">
    <pre class="moz-signature" cols="72">-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          <a class="moz-txt-link-freetext" href="mailto:jtuchel@objektfabrik.de">mailto:jtuchel@objektfabrik.de</a>
Fliederweg 1                         <a class="moz-txt-link-freetext" href="http://www.objektfabrik.de/">http://www.objektfabrik.de</a>
D-71640 Ludwigsburg                  <a class="moz-txt-link-freetext" href="http://joachimtuchel.wordpress.com/">http://joachimtuchel.wordpress.com</a>
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

</pre>
  </div>

_______________________________________________<br class="">seaside mailing list<br class=""><a href="mailto:seaside@lists.squeakfoundation.org" class="">seaside@lists.squeakfoundation.org</a><br class="">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br class=""></div></blockquote></div><br class=""></div></body></html>