Customize rules and behavior settings
Define rules and behaviors for your API Acceleration property.
Your property configuration includes default rules from when you first create a configuration. For an API Acceleration property POST, PUT, PATCH, and DELETE are enabled by default. Define the match criteria and enable caching for cacheable content.
Depending on what modules are available in your contract, you can enable additional features. You’ll add these behaviors via the Add Rule and Add Behavior buttons to take advantage of various API Acceleration features.
|Origin Server Hostname||This is the hostname of the
server that contains content that you want to be delivered from the edge network.
When you set the origin in your configuration, you also assign an origin hostname to
use in your DNS as described in Identify origin server.
If your application uses NetStorage, you will also need:
|Forward HOST Header||The Forward HOST Header is
the hostname the server forwards to the origin. This header is included in the HTTP
HOST request header. The Web server on your origin uses this value to determine what
content to send. Typically, the expected host is the same name as the digital
property received in the request. However, it may be customized.
When determining which Forward HOST Header to use, your options include the HTTP Host Header included in the original request, the origin server hostname you specified in this feature, or a custom host header.
|Origin SSL Certificate Name||If you are using the Secure Option, enter the SSL certificate that is specified for the configuration. This certificate should carry the same common name as the primary digital property.|
|Origin Server Port||You have the option of setting a non-standard, unrestricted port that servers will use to communicate with the origin.|
|Root Directory||This setting is only for configurations that do not use the root directory of the origin server host. Complete this field only if you are using a subdirectory as your root directory.|
|Compression Support||Compression is important in
optimizing performance. If your origin supports compression/gzip, you can direct the
server to send the
Select this option
only if your origin server supports both compression/gzip and the
|Cache Key — Origin Server||Our servers use the cache key to identify the content in caches. Assuming your
application includes at least some cacheable content, by default Akamai uses keys based on the entire origin uniform resource identifier
(URI) path and query string, if there is one.
If you want to use a cache key, you can select one of these options:
The server names are case-sensitive by default, but you can set your configuration to be case insensitive. Setting this feature is an instruction to ignore case in operations like the creation of cache index keys. This means that the URL and any associated query key is converted to all lower case when the cache key is created. As a result, URLs that fetch the same object using a different case will now cache the object only once rather than caching each uniquely-cased URL.
Last Mile Acceleration
|Content with character encoding||
Caching: Time-to-Live/Max-Age settings
Time-to-Live (TTL) rules, also known as Max-Age rules, are a set of options by which the content objects are either cached or not cached by Akamai edge servers. You configure the TTL/Max-Age setting via Property Manager as part of the Caching behavior. You can choose units of seconds, minutes, hours, or days for the TTL/Max-Age setting.
If your caching behavior is set to no-store or bypass-cache, the Edge Server sends “cache-busting” headers downstream. This table provides additional information on these options.
|no-store||When you select this option, you disallow caching in platform servers and in downstream caches.|
|bypass-cache||When you select this
option, you do not serve
content from cache. Instead, a request is sent to the origin, and caching in
downstream caches is disallowed.
For example, this option may be useful when using central authorization, as it will bypass the cache for the client request. Once users are authenticated, they are redirected to cached content.