Our edge servers will typically forward the entire request to an origin server (e.g., customer origin serverRefers to a web server external to our network that will serve as the source from which content will be delivered. This type of web server must be defined in a customer origin configuration.).
Our CDN only accepts requests that comply with the HTTP specification (e.g., HTTP/1.1). We return a 400 Bad Request for non-compliant requests.
Rules Engine may be configured to override the default CDN behavior and alter the request sent to the origin server.
Every HTTP request must include instructions on how the request should be handled. This is known as an HTTP request methodIndicates the type of action that a server should perform on the asset identified in the request URL. Common HTTP request methods are GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, and CONNECT.. The default manner in which our CDN service handles these request methods is described below.
| Request Method | Cache?Indicates whether the CDN may generate cached content for requests that leverage the request method in question. | Proxy?Indicates whether the CDN may forward requests that leverage the request method in question to an origin server. | Request Size LimitIndicates the maximum allowed size of the request. Both request headers and the request body are included when calculating this size limitation. | |
|---|---|---|---|---|
|
Yes |
Yes |
Request headers onlyA request body should not be included when submitting a GET request. |
||
|
All other request methods (e.g., POST, PUT, and DELETE). |
No |
Yes (Customer Origin Server Only) |
100 MB |
By default, only GET requests are eligible for caching. Use the Cacheable HTTP Methods feature to allow caching for POST and/or PUT requests. Although you may enable caching for POST and PUT requests, purge is only supported for GET requests.
Your CDN setup, including security measures, may place further restrictions on when content will be cached or proxied.
The CDN service communicates using the HTTP protocol version (i.e., HTTP/1.0 or HTTP/1.1) defined in the request.
The HTTP/2.0 protocol version is only used for the communication between the client and the edge of our network.
Learn more.
Requests that are proxied through our network to an origin server will include the entire CDN or edge CNAME URL submitted by the requester. If the requested URL includes a query stringRefers to data that is appended to a URL (e.g., "?Data=xyz" in the following request: http://www.server.com/index.html?Data=xyz). This information may be used in a variety of ways. Our CDN allows each query string variation of a URL to generate a unique cached asset. Additionally, query string information may be stored in our log files., then it will also be forwarded to the origin server.
Request URLs, with the exception of the schemeFor the purpose of HTTP traffic, it identifies whether traffic should use the HTTP or HTTPS protocol. The syntax for a URL scheme consists of the protocol, a colon, and two forward slashes (e.g., http:// or https://). and domain name, are case-sensitive.
We return a 400 Bad Request if a request contains a header that does not comply with the HTTP specification (e.g., HTTP/1.1). For example, we will not accept a request with a header that contains whitespace between its name and the colon.
By default, all request headers may be forwarded to the origin server. Our edge servers may also add or overwrite the following reserved request headers:
| Request Header | Description | Example |
|---|---|---|
|
User-Agent |
Identifies or describes the software agent that submitted the request. The value that will be passed to an origin server varies according to request type. Request types:
|
EdgeAccel/2.0 |
|
Identifies the edge server that proxied the request to an origin server. |
HTTP/1.1 ECS ( |
|
|
X-Forwarded-For |
Indicates the requester's IP address. |
10.10.10.10 |
|
X-Forwarded-Proto |
Indicates the request's protocol. |
http |
|
X-Host |
Indicates the request's hostname. |
cdn.mydomain.com |
|
X-Midgress |
Indicates whether the request was proxied through an additional CDN server (e.g., edge server to CAN Gateway server). This header will only be added to the request when midgress traffic takes place. |
1 |
|
Identifies the host and the port where the requested content may be found. |
marketing.mydomain.com:80 |
|
|
Identifies the failover list of CAN Gateway servers assigned to a customer origin. |
icn1,hhp1,hnd1 |
|
|
X-EC-Name |
Request headers that start with "X-EC" (e.g., X-EC-Tag, X-EC-Uuid, and X-EC-Session-ID) are reserved for use by the CDN. |
waf-production |
The format through which the Via request header will identify an edge server is indicated below.
The terms used in the above request header syntax are defined below:
POP: Indicates the POP that handled the request.
Example
A sample Via request header is provided below.
Our edge servers will overwrite the Host header when both of the following conditions are true:
The Host request header will be overwritten to reflect the value defined in the HTTP Host Header option.
If the customer origin's HTTP Host Header option is set to blank, then the Host request header submitted by the requester will be forwarded to that customer origin server.
An edge server will add/overwrite the X-Gateway-List request header when the request points to the CAN platform.
Requests that are proxied through our network to an origin server will include a request bodyIdentifies the set of data sent from the requester. The most common usage of a request body for CDN traffic occurs with POST requests. except if either of the following conditions are true:
Rules Engine:
Edgecast CDN