Monday, September 26, 2005

Server side: ETag VS Cache-Control max-age=xxxx or Expiration VS Validation

I will not cover here the whole topic of the web caching, but there things, which I'd
like to mention. They are the two caching mechanism:
1) is configured in the server ( in IIS we can set expiration date or expiration timeout ( e.g. max-age ) and on Apache we even can set cache policy for different content types )
2) no configuration in the server ( client uses "ETags" for cache validation ) - the default one.

Now lets consider 1st way, we configure web-server and set expire time as 1 hour ( max-age = 3600 ). What will now happen? Client will download the resource with the header - Cache-Control: max-age = 3600, store this value and will also store the date, when that resource was downloaded. Then every time during 1 hour when client browser
receives reference to the resource he will check download date & max-age value of it, and if the content is up-to-date, browser will not send request to the server, and it will use cached resource.

On the other hand ( 2nd way ) server has no configuration settings. Every resource downloaded from the server has it own "ETag". Next time, when browser accesses the resource it sends request to the server, and server sends response, containing error - 304 ( not modified ). This code signals client to use cached version of the resource.

While analyzing these two techniques we can come to the conclusion:
1) when using 1st way - we reduce the number of server roundtrips, thus have better network performance.
2) when using 2nd way - we have greater number of roundtrips to check the resource ETag.

The pros and cons are the following here:
1st way, greater network performance but cache will be invalidated only after period of time 2nd way, lower network performance but cache will be invalidated correctly, when resource will be changed.

The above said in the HTTP spec it is stated as
"The former reduces the number of network round-trips required for many operations; we use an “expiration” mechanism for this purpose (see section 13.2). The latter reduces network bandwidth requirements; we use a “validation” mechanism for this purpose (see section 13.3)."

From the HTTP spec:
"Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases."

Update: actually 1-st and 2-nd methods can also be used togther. Using them combined can reduce not only the number of requests but also response size.
For instance if two methods are used together: the resource will at first expire and after that it will be checked (validated) for change.

11 comments:

  1. Thaks. this was helpful.

    ReplyDelete
  2. A little typo I noticed. As I understand it, the max-age directive is in seconds. 60[seconds] * 60[minutes] = 3600.

    So 1 hour would be max-age = 3600

    ReplyDelete
  3. Yes, you're right. Thanks, I'll correct that ASAP

    ReplyDelete
  4. I think you have things a little off, but I could be wrong.

    From my understanding of caching, max-age and etags are supposed to be used together. Up until the max-age, like you said, the client doesn't request any new material. But, after the max-age expires, the client will send an etag (which the server should have sent with the original file) for validation against the current etag on the server. If the two match, the client knows the data is still fresh, so it can continue to use it and it will update reset the max-age.

    ReplyDelete
  5. Etag and max-age are two different mechanisms. According to this, max-age header cannot be used.

    ReplyDelete
  6. When I said max-age and Etags were meant to be used together, i meant that you're supposed to use both of them, not that you could somehow include a max-age in your Etag header or vice-versa.

    My point was that you can't compare the Cache-Control:max-age = x header and the Etag header because they serve different purposes and, for optimal caching, you should use both.

    After rereading my comment, I realize it was pretty unclear. Here's my understanding of how the process works:

    Cache-Control:max-age = x tells the client that the content is GUARANTEED fresh for x seconds (that's why the client doesn't make any requests to the server before the max-age time is up-- like you said in your post).

    Once the x seconds have elapsed, the content is NO LONGER GUARANTEED FRESH, BUT MAY STILL BE. Therefore, the next time you request the cached element, the ETag is invoked for validation (i.e. rather than asking for the content again, the client asks for the new ETag to see if the content has changed. If the ETag has changed, it requests the new content, but otherwise it doesn't, saving time.)

    If that's unclear, here's a much more-detailed, better-written description of the caching process

    ReplyDelete
  7. ETag is a response header. Client has to do the request to get new etag (to detect resource change).

    While caching mechanism (max-age) implies that no network activity is made by the client because it believes that content is fresh.

    When max-age expires client sends request and receives response. That response may contain max-age and etag. But if it contains both: max-age has the precedence (client will not do any requests fox max-age: x seconds). If client is not making requests it has no ability to validate etag.

    That is why max-age and etag mechanisms should be uses separately.

    ReplyDelete
  8. Vadym,

    You point out that, after max-age expires, the client sends out a new request and the server issues a response. As I understood your point, you were saying that, if a max-age was included in the response, it would take precedence, and therefore it would be useless to use both; you should use one or the other.

    The point that you're overlooking is that not all responses are created equal.

    If, when the client first downloads the resource, the server only sends a max-age, but no ETag, the client will re-download the WHOLE RESOURCE in subsequent requests where the max-age has expired.

    However, if both an ETag and a max-age are included in the original response, the client will run a conditional request upon the max-age expiring. This means that, instead requesting the resource all over again, the client includes the original ETag with the request and tells the server to only send the new resource if the ETag has changed.

    So, like I was saying earlier, max-age sets an Expires time on the conten, while ETags can be used to see if, after the max-age is up, the content is still valid and no re-downloading is necessary.

    In case I'm still explaining myself poorly, I've included a few quotes from the official w3.org page on the HTTP 1.1 spec.

    From the introductory paragraph, explaining what I was trying to say about expiration vs. validation: "The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose (see section 13.2). The latter reduces network bandwidth requirements; we use a "validation" mechanism for this purpose (see section 13.3). "

    And, from the respective paragraphs on max-age and ETags.

    Of max-age:
    "The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future [so that] a cache can return a fresh response without first contacting the server."

    Of ETag:
    "When a cache has a stale entry that it would like to use as a response... it first has to check with the origin server to see if its cached entry is still usable. We call this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, the HTTP/1.1 protocol supports the use of conditional methods."

    ReplyDelete
  9. Yes, I missed the point about reducing response size.

    Now I see that these two cache methods can be used together. And that they complement each other.

    Thank you for your effort :)

    ReplyDelete
  10. hi people. I'm actually into shoes and I was looking as far as something that singular brand. The prices seeking the sneakers were all over 240 bucks on every site. But definitively I set this locate selling them for half price. I exceptionally like these [url=http://www.shoesempire.com]prada sneakers[/url]. I will probably buy those. what can you say about it?

    ReplyDelete
  11. Nice explanation. Just what I was looking for.

    Many thanks,

    ReplyDelete