Web Cache

While doing the project, I met a little problem that was really annoying in fact.

I had to manipulate XML document dynamically that was done by PHP. Everything worked well, the new data were written down XML document. When I had loaded the data from the XML document into HTML document immediately after manipulating them, however, the problem appeared. The new data was not as I had desired, it was still the old data. I tried to refresh the XML document in browser and it worked, I got the desired result.

In this case, there is something happened when I had loaded the XML document so it is necessary to refresh the XML document in other to get the desired result.

The something that I mentioned above is caching or web cache.

What’s a Web Cache? Why do people use them?

A Web cache sits between one or more Web servers (also known as origin servers) and a client or many clients, and watches requests come by, saving copies of the responses — like HTML pages, images and files (collectively known as representations) — for itself. Then, if there is another request for the same URL, it can use the response that it has, instead of asking the origin server for it again.

There are two main reasons that Web caches are used:

• To reduce latency — Because the request is satisfied from the cache (which is closer to the client) instead of the origin server, it takes less time for it to get the representation and display it. This makes the Web seem more responsive.
• To reduce network traffic — Because representations are reused, it reduces the amount of bandwidth used by a client. This saves money if the client is paying for traffic, and keeps their bandwidth requirements lower and more manageable.

How Web Caches Work?

All caches have a set of rules that they use to determine when to serve a representation from the cache, if it’s available. Some of these rules are set in the protocols (HTTP 1.0 and 1.1), and some are set by the administrator of the cache (either the user of the browser cache, or the proxy administrator).

Generally speaking, these are the most common rules that are followed (don’t worry if you don’t understand the details, it will be explained below):

1. If the response’s headers tell the cache not to keep it, it won’t.
2. If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.
3. A cached representation is considered fresh(that is, able to be sent to a client without checking with the origin server) if:
   • It has an expiry time or other age-controlling header set, and is still within the fresh period, or
   • If the cache has seen the representation recently, and it was modified relatively long ago.

   Fresh representations are served directly from the cache, without checking with the origin server.

4. If an representation is stale, the origin server will be asked to validate it, or tell the cache whether the copy that it has is still good.
5. Under certain circumstances — for example, when it’s disconnected from a network — a cache can serve stale responses without checking with the origin server.

If no validator (an ETag or Last-Modified header) is present on a response, and it doesn’t have any explicit freshness information, it will usually — but not always — be considered uncacheable.

Together, freshness and validation are the most important ways that a cache works with content. A fresh representation will be available instantly from the cache, while a validated representation will avoid sending the entire representation over again if it hasn’t changed.

Source: http://www.mnot.net/cache_docs/

Just with answers of two above questions, I solved the problem in my project. Though there are still solutions somewhere on internet, I think that it is important and recommended to understand fundamental level of something. It is very useful to solve flexibly a problem that may be creativity in some way.

Anyway, I have a quote about this.

“Sometimes you need leaves. Sometimes you need roots”