Dell DX6004S DX Object Storage Application Guide - Page 71

Using Caching Metadata Headers

Page 71 highlights

Chapter 18. Using Caching Metadata Headers This chapter discusses caching metadata headers, which enables clients and caching proxies to quickly determine whether or not a resource has been modified since the last time it was read. For a list of all metadata headers supported by DX Storage, see the Content Metadata appendix. 18.1. About Caching Headers HTTP defines several header mechanisms for clients and caching proxies to be able to quickly determine whether a resource has been modified since the last time the data was read. Within the DX Storage context, caching headers make proxies more effective by extending the caching period to its maximum value, essentially telling the proxies, this resource will not change for immutable objects. With anchor streams, utilization of the caching headers provides a mechanism for clients to determine if the previous read is the current revision prior to writing an update to an anchor stream. In order to maintain compatibility with a wide variety of browsers and proxies, DX Storage implements the caching mechanisms for both HTTP/1.0 and HTTP/1.1. 18.2. Using HTTP/1.0 Caching Headers In the first version of HTTP, the cache coherency mechanism used time stamps with one second granularity to decide if a resource had been modified and therefore required invalidating the cached copy. In addition to the course time granularity which could mask changes made (to anchor streams for example) in the same second, this approach also requires the client and/or proxy clocks to be reasonably well synchronized with the server clocks. Although DX Storage will support this coherency method for compatibility reasons, it is not the preferred mechanism because of these objections. Note that the value of each header is an HTTP-date as defined in RFC2616. 18.2.1. Last-Modified DX Storage will return the Last-Modified header for all POST, PUT, GET, and HEAD operations. For both ordinary objects and anchor streams, the value of the header will be exactly the same as the Castor-System-Created header. For ordinary objects, this is the original creation time stamp for the object. For anchor streams, this is the server time at which the alias was last updated. The Castor-System-Created header will be deprecated and its use within DX Storage will be replaced with the more standard Last-Modified header. For backward compatibility with previously stored data, DX Storage will continue to generate both headers and behave as it does now if it encounters an object with a Castor-System-Created header but without a Last-Modified header. If a stored object includes both headers, DX Storage will use the value of the Last-Modified header. A future release will cease generating the deprecated header for newly stored content. 18.2.2. If-Modified-Since A DX Storage client or proxy can include this header with a GET or HEAD method request. All other methods will ignore the header if it is present in the request. The If-Modified-Since request header field is used with a GET to make it conditional. If the requested object has not been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 Not modified response will be returned without any message-body. Please reference section 14.25 of the HTTP/1.1 specification for full details. 18.2.3. If-Unmodified-Since A DX Storage client or proxy can include this header with any of the following methods: GET, PUT, and DELETE. All other methods will ignore this header if present in the request. The If-Unmodified- Copyright © 2010 Caringo, Inc. All rights reserved 66 Version 5.0 December 2010

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81

Copyright © 2010 Caringo, Inc.
All rights reserved
66
Version 5.0
December 2010
Chapter 18. Using Caching Metadata Headers
This chapter discusses caching metadata headers, which enables clients and caching proxies to
quickly determine whether or not a resource has been modified since the last time it was read.
For a list of all metadata headers supported by DX Storage, see
the Content Metadata appendix
.
18.1. About Caching Headers
HTTP defines several header mechanisms for clients and caching proxies to be able to quickly
determine whether a resource has been modified since the last time the data was read. Within the
DX Storage context, caching headers make proxies more effective by extending the caching period
to its maximum value, essentially telling the proxies, this resource will not change for immutable
objects. With anchor streams, utilization of the caching headers provides a mechanism for clients
to determine if the previous read is the current revision prior to writing an update to an anchor
stream. In order to maintain compatibility with a wide variety of browsers and proxies, DX Storage
implements the caching mechanisms for both HTTP/1.0 and HTTP/1.1.
18.2. Using HTTP/1.0 Caching Headers
In the first version of HTTP, the cache coherency mechanism used time stamps with one second
granularity to decide if a resource had been modified and therefore required invalidating the cached
copy. In addition to the course time granularity which could mask changes made (to anchor streams
for example) in the same second, this approach also requires the client and/or proxy clocks to
be reasonably well synchronized with the server clocks. Although DX Storage will support this
coherency method for compatibility reasons, it is not the preferred mechanism because of these
objections. Note that the value of each header is an HTTP-date as defined in RFC2616.
18.2.1. Last-Modified
DX Storage will return the Last-Modified header for all POST, PUT, GET, and HEAD operations. For
both ordinary objects and anchor streams, the value of the header will be exactly the same as the
Castor-System-Created header. For ordinary objects, this is the original creation time stamp for the
object. For anchor streams, this is the server time at which the alias was last updated.
The Castor-System-Created header will be deprecated and its use within DX Storage will be
replaced with the more standard Last-Modified header. For backward compatibility with previously
stored data, DX Storage will continue to generate both headers and behave as it does now if it
encounters an object with a Castor-System-Created header but without a Last-Modified header. If a
stored object includes both headers, DX Storage will use the value of the Last-Modified header. A
future release will cease generating the deprecated header for newly stored content.
18.2.2. If-Modified-Since
A DX Storage client or proxy can include this header with a GET or HEAD method request. All other
methods will ignore the header if it is present in the request. The If-Modified-Since request header
field is used with a GET to make it conditional. If the requested object has not been modified since
the time specified in this field, an entity will not be returned from the server; instead, a 304 Not
modified response will be returned without any message-body. Please reference
section 14.25
of
the HTTP/1.1 specification for full details.
18.2.3. If-Unmodified-Since
A DX Storage client or proxy can include this header with any of the following methods: GET, PUT,
and DELETE. All other methods will ignore this header if present in the request. The If-Unmodified-