Response

A user's request for content will generate a responseConsists of the headers and the body sent from a server responding to a request. If an origin server is returning a response, then this response will be sent to an edge server. The edge server will then forward the response to a client. from a server. This response consists of:

• Protocol and Version
• Status Code
• Response Headers
• Response Body

Protocol and Version

Identifies the network protocol and version (e.g., HTTP/1.1) used to transmit the response to the client. This protocol and version typically matches the one defined in the request. If an invalid protocol or version was requested, then the response will return a 505 HTTP Version Not Supported.

Status Codes

Upon attempting to fulfill a request, a server (e.g., an edge server or an external web server) returns a status code that indicates the result.

Our features, such as Rules Engine, Token-Based Authentication, and Web Application Firewall (WAF), may override this status code. For example, upon blocking malicious traffic, WAF can return a 403 Forbidden response to the client.

Although servers may return any type of status code, they typically return one of the following types of status codes:

• Standard Status Codes

  Servers typically respond with a standard status code for most web traffic. Internet Assigned Numbers Authority (IANA) maintains a list of standard status codes (e.g., 200 OK and 404 Not Found). These status codes fall within the following range: 100 - 599.

  View common HTTP status codes.

  Common HTTP status codes are described below.

  HTTP Status Code	Description
  200 OK	Indicates that the requested content was delivered to an authorized user. HTTP Large/HTTP Small Only: By default, the response will be cached unless the asset’s headers specifically prohibit caching. ADN: By default, the response will not be cached.
  302 Found	Indicates one of the following took place: URL redirection Cookie revalidation
  304 Not Modified	Indicates all of the following: A request for stale content was revalidated. The time-to-live (TTL) of the requested content has been updated. The requested content was delivered to an authorized user.
  403 Forbidden	This status code is returned to a user in response to an unauthorized request. The requester will be denied access to the requested asset. A request for an asset protected by Token-Based Authentication is considered unauthorized when: It does not include a valid token. The requester does not meet the conditions specified in the included token.
  404 Not Found	An origin server returns this status code when the requested asset was not found.
  504 Gateway Timeout	An edge server returns this status code when it is unable to communicate with an origin server when trying to revalidate the requested asset.

• Reserved Status Codes

  Our CDN reserves the 700 - 999 status code range for communication between our servers.

  Key information:

  • Your servers should not return a reserved status code. This type of setup may cause unexpected behavior.
  • A common reserved status code is 893. Our edge servers return this status code when load balancing high volume traffic for a specific asset within a POP.
  • These reserved status codes are solely used for communication within our internal network and are not served to clients. However, they may appear within log data under certain circumstances.

Response Headers

The response headers generated for content requested through our CDN describe the response provided by an edge server. By default, our edge servers will include:

• Response headers generated by the origin serverRefers to the server(s) where content served via the CDN is stored. There are two types of origin servers, which are CDN and customer origin servers. All requests that cannot be fulfilled directly by an edge server are forwarded to an origin server. For example, a request for content that has not been previously cached is forwarded from an edge server to an origin server..

  Example:

  The Last-Modified and ETag response headers determine whether our edge servers will be able to revalidateRefers to the process that occurs when a request for stale content requires that our edge servers check for a new version of the requested content on the origin server.staleIdentifies cached content whose TTL has expired. Our edge servers revalidate stale content with the origin server. This step ensures that the latest version of the requested content is served to the requester. content.

  Learn more.

• Response headers that describe the response (i.e., date, size, and content type).
• Response headers that define or describe the requested content's cache policy.
• Information that identifies the edge server that served the response.

Common Response Headers

Common response headers are listed below.

Response Header	Description
Accept-Ranges	Indicates whether a server can accept range requests. Default value: bytes The default value indicates that our servers can accept byte-range requests.
Cache-Control: max-age	Indicates the maximum length of time that a request is considered fresh. An edge server can serve fresh content directly from cache without having to perform a revalidation with the origin server. Default value: 604800 The default value indicates that the max-age for the requested content is 7 daysMax-age is defined in seconds. 604800 seconds = 7 days.
Content-Type	Indicates the media typeIdentifies/classifies the data contained in a file. (aka content type) for the response body. Sample media types are provided below. text/plain text/html text/css application/x-javascript text/javascript
Date	Indicates the date and time (GMT) on which the edge server returned a response.
Etag	Indicates the entity tag (ETag) for the requested content. This ETag allows our edge servers to revalidate stale content. In other words, our edge servers will use ETag when checking with the origin server to see if there is a newer version of the requested content.
Expires	Indicates the date and time (GMT) at which the response will be considered stale. By default, our edge servers must revalidate requests for stale content.
Last-Modified	Indicates the date and time (GMT) at which the requested content was last updated.
Server	Provides information about the server that fulfilled the request. Syntax (Customer Origin Server) If a cached version of the requested content is not found, then the customer origin server will provide a response. Server Response Header: If a Server response header is provided by the customer origin server, then our edge servers will forward it to the requester. Missing Server Response Header: If the Server response header is missing, then information about the edge server that fulfilled the request will be returned to the requester. Please see the syntax for cached content. Syntax (New Content & CDN Storage) The following syntax applies for requests to CDN storage that have not been previously cached: EOS (POP/IDIndicates a four digit alphanumeric system ID. This field is used solely for internal purposes.) The terms used in the above syntax are defined below: POP: Indicates the POP that handled the request. View a list of POPs. ID: Indicates a four digit alphanumeric system ID. This field is used solely for internal purposes. Syntax (Cached Content) The following syntax applies for requests for cached content: Platform (POP/IDIndicates a four digit alphanumeric system ID. This field is used solely for internal purposes.) The terms used in the above syntax are defined below: Platform: Indicates the platform on which the content was requested. The following codes are valid for this field: Code Platform ECAcc HTTP Large ECS HTTP Small ECD Application Delivery Network (ADN) POP: Indicates the POP that handled the request. View a list of POPs. ID: This field is for internal use only.
Warning	This response header is only returned when a staleIdentifies cached content whose TTL has expired. Our edge servers revalidate stale content with the origin server. This step ensures that the latest version of the requested content is served to the requester. response is served to the client. A stale response is typically served under the following conditions: The Stale While Revalidate feature was applied to the request. Response header value: 110 - "Response is stale" RevalidationCache revalidation is the process through which an edge server checks the origin server for a newer version of a cached asset. Revalidation is triggered when the TTL for the requested content has expired. failed and either of the following conditions is true: The origin server returned a 5xx response and the Stale Content Delivery on Error feature was applied to the request. The origin server is unresponsive and the stale window, as defined by the Internal Max-Stale feature, is active. Response header value: 111 - "Revalidation Failed", 110 - "Response is stale"
Vary	Identifies the variant that defines whether cached content can be served for future requests. Key information: Our network only supports a single variant called "Accept-Encoding." This value indicates that the Accept-Encoding request header determines whether cached content will be served. By default, our edge servers only return this header when the requested content was previously cached. The Accept-Encoding request header identifies the type of compression requested by the client. An edge server may deliver the requested content immediately if the cached asset matches the requested compression method.
X-Cache	Indicates that a cached version of the requested content was served directly to the requester by an edge server. This response header will be set to the following value: HIT: Indicates that a cached version of the requested content was found and served to the user.
Content-Encoding	Indicates that a compressed version of the requested content was served to the requester. This response header will indicate the asset's compression type (e.g., gzip, deflate, bzip2, etc.).
Content-Length	Indicates the size of the response body in octets.

Use the Debug Cache Response Headers feature to add debug cache headers to the response.
Learn more.

Viewing Response Headers

Response headers can be viewed using a variety of tools, such as:

• Chrome Developer Tools
• Firebug
• Fiddler
• Wget
• curl

Chrome Developer Tools

Chrome offers built-in developer tools through which you may view response headers.

To view response headers in Chrome

1. Load Chrome.
2. Press CTRL+SHIFT+I.
3. Click Network.
4. Request the desired content.
5. Click on the name of the desired asset.
6. Click on the Headers tab.

If you would like to submit this information to support personnel, right-click on the left-hand pane and then select the Save as HAR with content option. Attach the HAR file to your message.

Firebug

Firebug is a free browser add-on for Mozilla Firefox.

To view response headers in FireFox

1. Load FireFox.
2. Load Firebug by clicking on it from the FireFox toolbar.
3. Click on the Net tab.
4. Request the desired content.
5. Click on the desired request.

Fiddler

Fiddler is a free web debugging tool. Although it has a variety of uses, it can be used to submit a request and view the corresponding response from the server. This tool provides a history of the requests submitted during the current session. This history, along with the verbose nature of this tool, makes it a useful troubleshooting tool through which you can diagnose the root cause of your issue.

Wget

Use Wget, which is a command-line tool, to request content.

The following sample request will return header data for content delivered over the HTTP Large platform.

curl

Use curl, which is a command-line tool, to request content.

The following sample request returns header data for content delivered over the HTTP Large platform.

Response Body

Contains the data provided in response to the request.

Example

The response body for a GET request for a text file might look similar to the following: