Dell DX6004S DX Object Storage Application Guide - Page 75

Using Custom Metadata Headers

Page 75 highlights

Chapter 19. Using Custom Metadata Headers This chapter discusses custom metadata headers, which you can use to pass any data your application requires. For a list of all metadata headers supported by DX Storage, see the Content Metadata appendix. Starting with DX Storage version 5.0, you can use custom headers in the following formats: • CAStor-* • x-*-meta-* The x-*-meta-* header is available with DX Storage version 5.0 and later. Examples: x-ExampleCorp-meta-color: blue x-xml-meta-data: largeblue DX Storage stores these headers and their supplied values without parsing, validation, or modification. Headers of any other type than the those defined in the HTTP 1.1 RFC or the preceding are silently ignored and are not persisted to the DX Storage cluster. Note Metadata of the formatCAStor-* or x-*-meta-* is case-insensitive (to be consistent with the HTTP 1.1 RFC and can contain ASCII characters only. The total length of all persisted metadata, keys and values, is limited to 32k octets. Metadata of a larger size results in a 400 (Bad Request) error response from DX Storage. The preceding custom headers can be used with HTTP POST, PUT, or COPY methods. You should include custom metadata on stored objects to provide information that can be used by DX Content Router to perform disaster recovery replication. Even if you have no current plans to use DX Content Router, you should start using custom metadata early in your deployment when content is first stored, particularly for non-anchor objects. The reason is that content metadata, like the object, is immutable and cannot be changed after it is written. The metadata on anchor streams can be updated after the initial write using the COPY method. Copyright © 2010 Caringo, Inc. All rights reserved 70 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
70
Version 5.0
December 2010
Chapter 19. Using Custom Metadata Headers
This chapter discusses custom metadata headers, which you can use to pass any data your
application requires.
For a list of all metadata headers supported by DX Storage, see
the Content Metadata appendix
.
Starting with DX Storage version 5.0, you can use custom headers in the following formats:
CAStor-*
x-*-meta-*
The
x-*-meta-*
header is available with DX Storage version 5.0 and later.
Examples:
x-ExampleCorp-meta-color: blue
x-xml-meta-data: <size>large</size><color>blue</color><specialorder/>
DX Storage stores these headers and their supplied values without parsing, validation, or
modification. Headers of any other type than the those defined in
the HTTP 1.1 RFC
or the
preceding are silently ignored and are not persisted to the DX Storage cluster.
Note
Metadata of the format
CAStor-*
or
x-*-meta-*
is case-insensitive (to be consistent
with
the HTTP 1.1 RFC
and can contain ASCII characters only. The total length of all
persisted metadata, keys and values, is limited to 32k octets. Metadata of a larger size
results in a 400 (Bad Request) error response from DX Storage.
The preceding custom headers can be used with HTTP POST, PUT, or COPY methods.
You should include custom metadata on stored objects to provide information that can be used by
DX Content Router to perform disaster recovery replication. Even if you have no current plans to
use DX Content Router, you should start using custom metadata early in your deployment when
content is first stored, particularly for non-anchor objects. The reason is that content metadata, like
the object, is immutable and cannot be changed after it is written. The metadata on anchor streams
can be updated after the initial write using the COPY method.