• 19 September 2024

When a website uses ArvanCloud CDN for acceleration and security, requests from that website’s visitors go to ArvanCloud’s CDN servers instead of the main server hosting the website. In response to these requests, the CDN edge server sends several headers to the visitor, which can be used to know the status of the sent request and also the server’s response.

If the sent headers from the CDN servers are specially created by the ArvanCloud, the word “ar”, which is the first two letters of ArvanCloud, is placed at the beginning of them.

Also, if a request is sent from the CDN edge server to the origin server hosting the website, headers are added to this request.

In the following, each of these headers and their explanations is stated.

Sent Headers to The User

x-request-id

This header assigns a unique code to each request sent from the visitor’s side to the CDN edge server; in the case that is needed, it can be tracked to find out about the status of the request on the CDN side.

x-poweredby

It returns the value ArvanCloud (arvancloud.ir) in the response and indicates the use of the ArvanCloud CDN by the target website.

x-sid

 A four-digit code indicating the unique number of the CDN server to which the visitor is connected.

x-time

This header indicates how long it took the CDN server to receive the relevant content. This can be received from the CDN’s cache or the main server of the site host.

x-cache

When the resources of your website are cached on the edge servers of ArvanCloud, ArvanCloud provides you with a special header named x-cache to be aware of the cache status of these resources. In this header, the Cache status can be one of the following:

  • HIT

This status in x-cache indicates that the requested resource has been cached in the ArvanCloud edge server and the response is from these servers.

  • MISS

This status means that the requested resource cache does not exist in the ArvanCloud edge server and it is answered by the main server of the website host.

  • EXPIRED

This status means that the requested resource cache exists in the ArvanCloud edge server, but due to its expiration, the response to this request has been made from the main server of the website.

  • STALE

This status indicates that ArvanCloud’s edge server has sent an old and expired resource in response because it is simultaneously validating this resource from the main server hosting the site due to another user’s request. It should be said that such a situation occurs very rarely.

  • IGNORED

This state means that the requested resource cannot be cached, but since the number of requests has not yet reached the allowed threshold (usually 3), this request has been answered by the main server hosting the site. After the number of requests exceeds the allowed threshold, this status turns into HIT.

  • REVALIDATED

This status means that ArvanCloud’s edge server used the old version of the requested resource that was in its cache to respond but the difference, in this case, is, the edge server uses the If-Modified-Since or If-None-Match headers to validate it.

  • UPDATING

This status indicates that the requested resource is being updated on the ArvanCloud edge server, and the response that was sent is the old version in the cache of this server. This situation usually happens when a large resource is being cached on the edge server.

x-xss-protection

An XSS attack is a type of web-based vulnerability that exists in many websites. Unfortunately, web developers ignore this bug or don’t know enough about how to prevent it. This security breach is very dangerous. Using various methods, the attacker transfuses his arbitrary JavaScript script or HTML code into the user or users of the page that has an XSS bug. Then these codes are executed on the user’s browser and expose the user to various and very dangerous risks. Modern browsers have several capabilities to deal with XSS attacks, which are usually enabled by default. To use this browser feature, the only thing that should be done is to use the x-XSS-protection header in response to a browser request.

X-Content-Type-Options

Some browsers do not trust the content-type header and sniff the content itself. The historical reason for this issue is that in the past there were servers whose sent content was different from this header and as a result, the browser had to sniff the content. Mime Sniffing detects this type of behavior when the browser does not receive the type of content sent in the Response header or notices a discrepancy in it. The method of these identifications can be different in each browser, but it is usually based on the sent type and desired extension. In some cases, reading the first bytes of a file can indicate the type of content being sent. For example, for files with the extension Gif, the starting byte pattern includes 47 49 46 38 39; But because in all files, the initial bytes do not have the same pattern, so this method cannot be enough. Another way to tell the browser to prevent this type of attacks and to stop executing it when Sniffing is detected, is to use the X-Content-Type-Options header.

Content-Security-Policy

When a website uses the HTTPS protocol, but there are still links with the HTTP protocol in its HTML pages, to maintain security, an error called Mix-Content is shown by the browser, which means the possibility of creating a security problem on the HTTP links.

There is an option in the ArvanCloud panel and in the HTTPS settings section that can be used to fix this problem.

By activating this feature, the Content-Security-Policy header is added to the sent headers to the user, and in this way, the browser is informed to change the desired link from HTTP to HTTPS if it encounters such a problem.

strict-transport-security

By activating the HSTS header in ArvanCloud’s CDN panel, this header is added to the sent header, and in this way, the browser is informed that for a certain period (such as a month), if the first request for the desired website was HTTP, automatically convert it to an HTTPS request from the browser side.

Headers Sent to The Main Server

x-sid

 It is a four-digit code and the unique number of the CDN server from which the request was sent.

X-Real-IP

X-Real-IP header is a standard HTTP header. When a website uses a CDN, if a request is sent from a visitor to the website, this request first reaches the CDN edge servers and then is sent to the main server of the website. Therefore, in the IP field of the request sender, instead of the real IP of the user, the IP of the CDN server is placed.

Because many analytical and security tasks require the user’s real IP, the CDN server uses this HTTP header to send the user’s real IP.

x-real-IP

It is similar to the X-Real-IP header.

X-Forwarded-proto header

X-Forwarded-proto is a standard HTTP header. This header, respectively, specifies the protocols that the request was used to pass through the CDN servers at each stage. For example, if a request is sent from the user’s side with the HTTP protocol to the CDN, and from the CDN to the main server with the HTTPS protocol, this header shows the HTTP and HTTPS values.

The protocol makes the connection between the visitor and the CDN servers, as well as between the CDN servers and the main servers of the website host, can be set separately in the ArvanCloud CDN panel.

X-Forwarded-For

This header is similar to the X-Real-IP header; the only difference is that the IP of the proxy servers which the user’s request has passed through to reach the main server of the site is placed next to the user’s main IP. This header is an array of IPs and indicates the order in which the request passes through multiple servers until it reaches the main server of the site host.

x-real-proto

It is similar to the X-Forwarded-Proto header.

x-real-country

This header indicates the country from which the request was sent. This information is obtained by using the user’s IP and extracting its country from the updated GeoIP databases.

x-request-ID

This header assigns a unique code to each request sent from a visitor to the CDN server so that when needed, it can be tracked to find out the status of the request on the CDN side.