The SetLastModified method of HttpCachePolicy adds the Last-Modified HTTP header to the response, and correctly encodes the specified timestamp. The browser will pass the timestamp to the server next time it tries to retrieve the content.

  Response.Cache.SetLastModified(ModifyDate);

Some clients, however, do not send conditional requests unless the ETag header is also specified. The ETag header contains a unique “entity tag.” Clients may use the entity tag instead of or in addition to the last modification date, so applications should provide both.

The entity tag must identify the exact version of the content. One method of generating such a unique identifier is to use the content name and last modification date. The following code generates an entity tag based on those parameters:

function GetFileETag(fileName: string; modifyDate: DateTime): string;
var
  FileString: string;
  StringEncoder: Encoder;
  StringBytes: array of Byte;
  MD5Enc: MD5CryptoServiceProvider;
begin
  { Use file name and modify date as the unique identifier }
  FileString := fileName + modifyDate.ToString;

  { Get string bytes }
  StringEncoder := Encoding.UTF8.GetEncoder;
  SetLength(StringBytes,
    StringEncoder.GetByteCount(
      FileString.ToCharArray, 0, Length(FileString), True));
  StringEncoder.GetBytes(FileString.ToCharArray, 0,
    Length(FileString), StringBytes, 0, True);

  { Hash string using MD5 and return the hex-encoded hash }
  MD5Enc := MD5CryptoServiceProvider.Create;
  Result :=
    '"' + BitConverter.ToString(
      MD5Enc.ComputeHash(StringBytes)).Replace('-', '') + '"';
end;

The double quotes added by the function are expected by the HTTP 1.1 specification for entity tags.

The SetETag method of the HttpCachePolicy class adds the ETag header to the response. However, there are a few restrictions on the use of this method:

1. The SetETag method can only be called once. Calling it a second time will raise an exception.
2. The method does not add the double quotes expected by HTTP 1.1. If you use a different algorithm to create the tag, make sure you include the double quotes.
3. HttpCachePolicy will not add the header if the “cacheability” is set to Private, which is the default value. Unless you call the SetCacheability method with a different value, you’ll have to add the header by calling HttpRequest’s AppendHeader method.

As far as I can tell, that last restriction isn’t documented, and may be a bug.

You can specify cache expiration using the SetExpires, SetMaxAge, and SetSlidingExpiration methods. Most browsers will not send request for cached content until it expires. This means the server will not get the opportunity to check whether content had been updated, so only set expiration for content you know is not going to change within the specified timeframe.

If the application determines the cache is still valid, it may return a 304 HTTP status code:

  if not IsFileModified(fileName, modifyDate, ETag, request) then
  begin
    { File hasn't changed, so return HTTP 304 without retrieving the data }
    Response.StatusCode := 304;
    Response.StatusDescription := 'Not Modified';
    Response.&End;
    Exit;
  end;

A 304 response must not contain a message-body.

The code shown above isn’t actually HTTP 1.1 compliant. There are a couple of additional requirements:

• If a normal response would have included an ETag header, that header must also be included in the 304 response.
• Cache headers (Expires, Cache-Control, and/or Vary), if their values might differ from those sent in a previous response.

Since we always include the ETag header in normal responses, we must include it in 304 responses:

  if not IsFileModified(fileName, modifyDate, ETag, request) then
  begin
    { File hasn't changed, so return HTTP 304 without retrieving the data }
    response.StatusCode := 304;
    response.StatusDescription := 'Not Modified';
    response.Cache.SetCacheability(HttpCacheability.&Public);
    response.Cache.SetLastModified(ModifyDate);
    response.Cache.SetETag(ETag);
    response.&End;
    Exit;
  end;

There’s still one problem with the code, and it’s not obvious without checking the HTTP response at run-time: the Connection field is automatically added to the header, with its value set to close. This causes the browser to close the connection, which means the browser will have to open a new connection for future requests, which may affect performance.

The reason the field is added is that the content is empty, and because the browser doesn’t know what content to expect, it waits for additional data. The problem can be prevented by explicitly adding the Content-Length header. Since we’re not returning any data, we set the field value to 0:

  if not IsFileModified(fileName, modifyDate, ETag, request) then
  begin
    { File hasn't changed, so return HTTP 304 without retrieving the data }
    response.StatusCode := 304;
    response.StatusDescription := 'Not Modified';

    { Explicitly set the Content-Length header so the client doesn't wait for
      content but keeps the connection open for other requests }
    response.AddHeader('Content-Length', '0');

    response.Cache.SetCacheability(HttpCacheability.&Public);
    response.Cache.SetLastModified(ModifyDate);
    response.Cache.SetETag(ETag);
    response.&End;
    Exit;
  end;