Quick-n-Dirty: Disable Domino’s Cache for easier development

I am currently developing a larger application and have a lot of different mobile devices for testing purposes. After making some changes it is required that all test devices have the latest version of my XPages running, and that the clients get the latest version of the frontend libraries (CSJS, CSS, Images, etc.).

Because it is rather annoying to always check whether the browser cache is cleared or not I decided to disable the caching on the domino server directly via a web rule. This works really great and helps a lot during testing and designing.

In this example the caching for databases and their ressources in the folder /dev will be disabled:

1. Create a web rule for your Internet Sites

2. Set the type of the rule to „HTTP response headers

3. Fill in incoming pattern to /dev/*

4. For the „Expires header“ select „Always add header“ and set it to a date in the past

5. Add two custom headers and check the „override“ option:

  • Cache-Control: no-cache
  • Pragma: no-cache

6. Open the admin console and refresh the HTTP task:

tell http refresh

From now on the headers are always added and will force the browsers to reload the resource every time. Every ressource delivered by the domino server which is inside the /dev folder (contained in a databases) won’t be cached anymore. It works even for minimized libraries and SSL.

Dieser Beitrag wurde unter Allgemein, Infrastruktur, Server, Web abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

2 Antworten zu Quick-n-Dirty: Disable Domino’s Cache for easier development

  1. harkpabst_meliantrop sagt:

    This is not Domino’s cache, it is the browser’s cache that is (or might be) disabled. The technique itself works well, bu it is still up to the implementation of the user agent, if its cache is bypassed completely or not.
    Usually, if the latest response contained an Etag, the browser would include the If-none-Match header in its next request. If the server determins the Etag to be unchanged, it will responde with HTTP status 304 Not Modified and the actual HTTP body content will still be loaded from the browser’s cache (which is a very good thing).
    It should still be noted, that enforcing Cache-control: no-cache is not an advisable option for production systems. Quite contrary, you will generally want to instruct clients to cache static content, that hardly ever changes. Consequentially, you will need another mechanism to make sure, that production clients will update their cache accordingly (like adding dates or version numbers to your recources). And if you are doing this for production, you might also consider to do it for dev, so there is less of a need for this technique anyway.

    • Thanks for your comment.

      I am not sure why you describe how browser caching works, why you think that prohibiting to cache an resource in productive systems is not an option and why you argue that it is „still up to the implementation of the useragent“, and then talking about „Usually … the browser would include“ (which also depends on the useragent’s implementation). But you have overseen the most importent point: There are no ETags in Domino resources (as you can see in the screenshot above).

      And Sorry that I missed the word „behaviour“ in the title of this three year old post.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.