Show Menu
TOPICS×

Serving static (non-image) content

Image Serving provides a mechanism to manage non-image contents in catalogs and serve it via a separate context /is/content . The mechanism allows for configuring the TTL for each item separately.

Basic syntax

request
http:// server /is/content[/ catalog / item ][? modifiers ]
server
server_address [: port ]
catalog
Catalog identifier.
item
Static content item ID.
modifiers
command *[& command ]
command
cmdName = value
cmdName
One of the supported command names.
value
Command value.

Command overview

Image Serving supports the following commands at /is/content:
type
Content type filter.
req
req=userdata , req=props , and req=exists only.
cache
Allows disabling client-side caching.

Static content catalogs

Static content catalogs are similar to image catalogs, but support fewer data fields:
Attribute/Data Notes
catalog::Id
The catalog record identifier for this static content item
catalog::Path
The file path for this content item
catalog::Expiration
The TTL for this content item; attribute::Expiration is used if not specified or if empty
catalog::TimeStamp
File modification time stamp; required when catalog-based validation is enabled with attribute::CacheValidationPolicy
catalog::UserData
Optional metadata associated with this static content item; available to the client with req=userdata
catalog::UserType
Optional data type; can be used to filter requests for static content with the type= command

Filtering static content

This mechanism can help ensure that clients receive only contents appropriate for their needs. Assuming that the static content is tagged with appropriate catalog::UserType values, the client can add the type= command to the request. Image Serving will compare the value provided with the type= command to the value of catalog::UserType and, in case of a mismatch, return an error instead of potentially inappropriate contents.