This topic explains how content may be compressed by your web servers.
Origin server compression requires the following setup:
The request must include an Accept-Encoding header set to one or more of the following compression types:
This header allows the user agentRefers to software that acts on behalf of a user. For example, a web browser (e.g., FireFox, Chrome, and Internet Explorer) is a user agent. A web browser will make HTTP/HTTPS requests based on user actions (e.g., requesting a web site or clicking a link). to indicate which compression methods it supports to the origin server.
This section explains the workflow through which content may be compressed by your web servers for HTTP Large and HTTP Small traffic.
A client may request compressed content from your web servers. If a supported compression type is requested, then compressed content will be served from your web servers and eventually be cached on our edge servers.
Detailed information on how requests are handled with regards to origin server compression is provided below.
Requester: A user submits a request for content. The manner in which this request is handled by our edge servers depends on whether the request includes the Accept-Encoding header.
Accept-Encoding Header | Description |
---|---|
Set to a supported compression method. |
This type of request will be handled as described in step 2. |
Set to an unsupported compression method. |
Our edge servers will always retrieve the requested content from your customer origin server. This type of request will not be cached and therefore will be handled as described in step 2's Cache Miss bullet item. |
Missing |
This type of request will be served in an uncompressed format as described by either the Cache Miss or the Uncompressed Cache Hit bullet item in step 2. |
POP: An edge server on the POP closest to the client will check to see if the requested content has been cached and if it still has a valid TTL.
Uncompressed Cache Hit: If the initial request caused the asset to be cached in an uncompressed format, then a check will be performed to see whether the request is eligible for edge server compression.
Origin Server: The manner in which the origin server will handle the request depends on whether both the CDN and your web servers support the compression method specified in the Accept-Encoding header.
CDN |
Customer Origin |
Request Workflow |
---|---|---|
Supported compression method |
Supported compression method |
|
Supported compression method |
Unsupported compression method |
|
Unsupported compression method |
Supported compression method |
|
Unsupported compression method |
Unsupported compression method |
|
This section explains the workflow through which content may be compressed by your web servers for ADN traffic.
A client may request compressed content from your web servers. If a supported compression type is requested, then compressed content will be served from your web servers. If the request is eligible for caching, then it will eventually be cached on an ADN Gateway server and our edge servers.
Detailed information on how requests are handled with regards to origin server compression is provided below.
Requester: A user submits a request for content. The manner in which this request is handled by our edge servers depends on whether the request includes the Accept-Encoding header.
Accept-Encoding Header | Description |
---|---|
Set to a supported compression method. |
This type of request will be handled as described in step 2. |
Set to an unsupported compression method. |
Our edge servers will always retrieve the requested content from your customer origin server. This type of request will not be cached and therefore will be handled as described in step 2's Cache Miss bullet item. |
Missing |
This type of request will be served in an uncompressed format as described by either the Cache Miss or the Uncompressed Cache Hit bullet item in step 2. |
POP: An edge server on the POP closest to the client will check to see if the requested content has been cached and if it still has a valid TTL.
Uncompressed Cache Hit: If the initial request caused the asset to be cached in an uncompressed format, then a check will be performed to see whether the request is eligible for edge server compression.
By default, content requested through the ADN platform will not be cached and therefore should result in a cache miss.
Origin Server: The manner in which the origin server will handle the request depends on whether both the CDN and your web servers support the compression method specified in the Accept-Encoding header.
CDN |
Customer Origin |
Request Workflow |
---|---|---|
Supported compression method |
Supported compression method |
|
Supported compression method |
Unsupported compression method |
|
Unsupported compression method |
Supported compression method |
|
Unsupported compression method |
Unsupported compression method |
|
Edgecast CDN