Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

A system of managing proxy and browser cache control on a web server

IP.com Disclosure Number: IPCOM000243662D
Publication Date: 2015-Oct-08
Document File: 2 page(s) / 36K

Publishing Venue

The IP.com Prior Art Database


Disclosed is a system and method for clearing client web browser cached resources without intervention from an end user or developer. The method and system uses a URL rewriter to alter the URLs to resources for a given web site at a server level so that a system administrator can clear the browser cache for all end users without development support.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 2

A system of managing proxy and browser cache control on a web server

When developing web applications, developers must always be aware of resource caching. Web browsers (and many commonly deployed proxy servers) will attempt to cache resources (images, JavaScript files etc.) to improve page load time and reduce network traffic. When resources are requested by a website, the browser/proxy sends a "HEAD" request to the server to check to see if a resource has changed. If the resource has not been modified (the browser looks at cache control headers, expiry dates, ETags etc.), a 304 Not Modified response is returned and the cached version of the resource is used.

    Depending on the website implementation, these cache control headers must be handled at the resource level which can be tedious and unreliable. A JavaScri's client frequently does not recognize the change and will continue to load the old version of the resource from cache. This can cause the page. This is not feasible for products with thousands of end users. As a result, when resources are updated on the server, an end user's unintended behavior in the application or potentially break the application entirely.

    The only way to truly guarantee a resource will not be loaded from cache after it has changed is to change its name (i.e., version the resource). Changing the name will change the URL to the resource. The browser/proxy will then see it as a new resource and download it from the server. Resource versioning is almost universally done at either a code level or build level. With so many applications now deployed in the cloud, it's often not feasible to involve a development team and update an application to solve caching problems for a small subset of users.

    Described here is a method of using a rewrite filter to alter the URLs to resources within web applications, at a server level, without a developer having to alter any code. This essentially allows the clearing of browser and proxy caches without having to modify any code and without the user having to clear their cache manually.

    At the web server level, a URL rewriter filter is added, so that all requests to, and responses from, the server pass through it. Lets say a user requests the page " http://web.server/myApp/myPage.html", which contains the markup shown in Figure 1.

    <script src="http://web.server/myApp/resources/aJSFile.js">
<body style="background-image:url('

Hello World.