{"id":9692,"date":"2018-03-15T16:51:22","date_gmt":"2018-03-15T14:51:22","guid":{"rendered":"https:\/\/help.superhosting.bg?p=9692"},"modified":"2022-03-18T16:22:47","modified_gmt":"2022-03-18T13:22:47","slug":"supercache-status-and-details","status":"publish","type":"ht_kb","link":"https:\/\/help.superhosting.bg\/en\/supercache-status-and-details.html","title":{"rendered":"Check, Status and Features of SuperCache"},"content":{"rendered":"

When you fine tune\u00a0SuperCache<\/a> and test its options, the special HTTP status headers generated will help you a lot. SuperCache’s system serves specific HTTP headers which provide information on the current system status and if a given web resource is cached or not.<\/p>\n

Important<\/strong>: Before checking how SuperCache works, you need to pay attention to the types of caching when using cookies and the excluded server headers from caching. These settings are available in SuperCache\u00a0\u00bb Advanced Settings\u00a0\u00bb Advanced Settings<\/a>.<\/div>\n

<\/a><\/p>\n

<\/a><\/p>\n

<\/span>How Caching in SuperCache Works?<\/strong> \"link-to-this-section\"<\/a><\/span><\/h3>\n

SuperCache is a\u00a0caching and web acceleration system<\/a> that applies basic caching techniques and approaches such as Reverse Proxy.<\/p>\n

When a given page from the website is loaded for the first time, SuperCache will keep a cached version of the page for future use.<\/p>\n

\"Cache<\/p>\n

Cache MISS<\/strong> \u2013 (the requested page is not available in the cache)<\/p>\n

(1<\/strong>) The web browser sends a query for the page.html web resource to the server corresponding to the requested domain, and the query reaches SuperCache.
\n(2<\/strong>) SuperCache looks for the requested page in the cache and does not find it. Such omission is called Cache MISS. SuperCache needs to access the website for the requested page.
\n(3<\/strong>) SuperCache sends a query for the page.html web resource to the source server.
\n(4<\/strong>) The source server returns the web page to SuperCache.
\n(5<\/strong>) SuperCache receives, copies the page in the cache and sends it back to the web client.
\n(6<\/strong>) The web browser receives the requested web resource.<\/p>\n

\"Cache<\/p>\n

Cache HIT<\/strong> \u2013 (the requested page is available in the cache)<\/p>\n

Once the page is cached, it is directly served upon next queries without sending new requests to the origin server.<\/p>\n

(1<\/strong>) The web browser sends a query for page.html to the server corresponding to the requested domain, and the query is detected by SuperCache (since the proxy server is located before the source server).
\n(2<\/strong>) SuperCache checks the cache for the requested page and finds it (Cache HIT). SuperCache serves the web page directly to the client, this time without turning to source server.<\/p>\n

back to the top\"back<\/a><\/div>\n

<\/a><\/p>\n

<\/span>Cache Check and Status in SuperCache<\/strong> \"link-to-this-section\"<\/a><\/span><\/h3>\n

Cache check might be performed either through the Developer Tool which is available by default in the more common browsers or through a console. The special header returned from SuperCache is checked during this procedure.<\/p>\n

\"Check<\/p>\n

Check through a Browser<\/strong><\/h5>\n

There is a Developer Tool available in Firefox and Chrome through which you can check the\u00a0HTTP headers<\/a> exchanged by the browser and SuperCache.<\/p>\n

To perform a check through Firefox or Chrome, load a webpage and press F12 (or Ctrl+Shift+K).<\/p>\n

Check the HTTP headers and look for the X-SH-Cache*<\/strong> header in the server\u2019s response.<\/p>\n

Check through a Console<\/strong><\/h5>\n

\"Check<\/p>\n

You can check the HTTP headers in the website\u2019s response also through a console.<\/p>\n

Cache tests can be performed through a remote machine.<\/p>\n

If the machine supports curl, here is what to use:<\/p>\n

curl -I http:\/\/cookies.goodexample.eu<\/p>\n

cookies.goodexample.eu – replace with the website\u2019s URL;<\/p>\n

HTTP status headers served by SuperCache
\n<\/strong><\/h4>\n

When a webpage is loaded with SuperCache activated, the server response headers will display one of the following special HTTP headers:<\/p>\n

X-SH-Cache-Status: HIT<\/strong>
\nThis status means that cached webpage content is served. Caching is activated and running.<\/p>\n

X-SH-Cache-Status: MISS<\/strong>
\nThis status means that cached content is not served. If you are visiting a webpage for the first time, you will get this status. Upon the next page loading, the status shall be HIT. If upon every next page loading the status is MISS, this means that there is a condition, HTTP header or an HTTP cookie preventing cashing.<\/p>\n

This status might be generated also if:
\n– the page is loaded for the first time;
\n– the website serves the Set-Cookie header which is not excluded from caching in SuperCache;
\n– the website serves a Cache-Control header with a directive restricting SuperCache from caching.<\/p>\n

X-SH-Cache-Status: BYPASS<\/strong>
\nThis status means that cached content is not served. The most common reason for this might be an excluded cookie which means that SuperCache will not serve cached content. BYPASS can be received in case a client cookie for authentication is generated that is excluded from caching. You can see these cookies below in the article.<\/p>\n

X-SH-Cache-Status: Excluded<\/strong>
\nThis status aims to inform you that cached content is not loaded for the webpage since its URL is excluded from caching. You can change this under Exclude URL Addresses from Caching.<\/p>\n

X-SH-Cache-Disabled: 1<\/strong>
\nThis status means that caching is deactivated in SuperCache Manager in cPanel. Cached version of the webpage is not served.<\/p>\n

X-SH-Cache-Status: EXPIRED<\/strong>
\nThis status means that the validity of the webpage\u2019s cached version has expired and it needs to be revalidated. Upon the next visit to the page the cached content will be refreshed and the status will change to HIT.<\/p>\n

X-SH-Cache-Status: Whitelisted Ip<\/strong>
\nThis status means that the IP address form which the query to the website is sent has been excluded from serving cached content.<\/p>\n

X-SH-WhitelistIp: xxx.xxx.xxx.xxx<\/strong>
\nThis header contains the IP address from which the query to the website is send.<\/p>\n

back to the top\"back<\/a><\/div>\n

<\/a><\/p>\n

<\/span>Specific Features of Caching with SuperCache<\/strong> \"link-to-this-section\"<\/a><\/span><\/h3>\n

HTTP Cookies
\n<\/strong><\/h4>\n

SuperCache supports three caching modes concerning the use of\u00a0HTTP Cookies in visitors\u2019 queries. The type of caching can be selected from the Types of Caching When Using Cookies<\/strong> option available under Advanced Settings<\/a> in SuperCache.<\/p>\n

To choose the suitable type of caching when using cookies you first need to test the website in details and define all cases in which it generates cookies. If there is a cookie enabling the website to provide personalized content for each user, you need to exclude this cookie from caching.<\/p>\n

HTTP Cookies Excluded from Caching<\/strong><\/h4>\n

Some of the most popular CMS such as WordPress, Joomla! and others use specific cookies to validate previous user identification. After logging into some of these systems\u2019 administrations, users receive the following cookies:<\/p>\n

admin<\/strong>=*
\nwordpress_logged_in<\/strong>*
\njoomla_user_state=logged_in<\/strong><\/p>\n

These administrative cookies are automatically excluded from caching. Removing this defense mechanism is not supported.<\/p>\n

When a user sends some of these cookies in the query to the website, SuperCache will return X-SH-Cache-Status:\u00a0BYPASS<\/strong> will neither cache the website\u2019s response, nor serve cached data to the visitor.<\/p>\n

If the website uses cookies for authentication different from the mentioned above, you can exclude them from Cache Everything Excluding Specific Visitor Cookies<\/strong> in Advanced Settings\u00a0\u00bb Types of Caching When Using Cookies<\/strong>. Enter only the cookie name in the field Do not Serve Content from the Cache when a Cookie is Present<\/strong>.<\/p>\n

Administrative URLs Excluded from Caching<\/strong><\/h4>\n

Just like administrative cookies, some of the administrative URLs in the most common CMS are excluded from caching.<\/p>\n

URLs Excluded from Caching:<\/p>\n

\/wp-admin<\/strong>
\n\/wp-login.php
\n<\/strong>\/administrator
\n<\/strong>\/admin<\/strong>
\n\/login<\/strong>
\n\/user\/login<\/strong>
\n\/?q=user<\/strong><\/p>\n

Unlike with cookies, the option for URLs Excluded from Caching can be deactivated. You can do this from Automatically Added URL Addresses which are Not Cached<\/strong> under\u00a0Advanced Settings<\/strong>\u00a0in SuperCache.<\/p>\n

Important<\/strong>: If for accessing the website’s admin panel you use a URL different from the excluded from caching ones, you must add it to Exclude URL Addresses from Caching in\u00a0SuperCache Settings<\/a>.<\/div>\n

HTTP Headers Served by the Website<\/strong><\/h4>\n

If a response from a website will be cached and until when the cache will be stored depends on the HTTP headers. SuperCache checks the HTTP headers in the website\u2019s response and complies with some of them.<\/p>\n

These are: Set-Cookie<\/strong><\/a>, Cache-Control<\/strong><\/a>, Expires<\/strong><\/a> and Vary<\/a><\/strong>.<\/p>\n

Note<\/strong>: Cache will be purged at certain time interval. The global interval for cache propagation is set up in SuperCache under Automatic Cache Purge. The interval set by default is 15 minutes. This means that cached data for a given web resource is purged every 15 minutes. Cached content is removed and upon next query this resource generates new cache.<\/div>\n
HTTP Set-Cookie Header<\/strong><\/h5>\n

The website sends\u00a0HTTP cookies\u00a0to users through this header. If the website\u2019s response contains at least one Set-Cookie header, it will not be cached by SuperCache. This option can be changed from Advanced Settings\u00a0\u00bb Disable the processing of the following server headers. After you exclude this header from processing, SuperCache will not comply with it and will freely cache the website\u2019s response.<\/p>\n

HTTP Cache-Control Header<\/strong><\/h5>\n

A number of directives from the HTTP Cache-Control Header are related to the website\u2019s response validity and control the way caching systems will process that response. This directly influences web resource caching and thus SuperCache is sensitive towards directives from the HTTP Cache-Control Header.<\/p>\n

HTTP Expires Header<\/strong><\/h5>\n

This header specifies the time until when the response is considered up-to-date. If the response is generated later than the specified date, the response is treated by caching systems as obsolete and outdated. SuperCache might exclude the Expires header if the response contains the HTTP Cache-Control header with a max-age directive.<\/p>\n

HTTP Vary Header<\/strong><\/h5>\n

HTTP Vary header<\/a>\u00a0is a mechanism used by websites for notifying that content varies depending on the specifications of the users.<\/p>\n

The header is used by caching systems so that they comply with this feature while caching content. It might use as directives other HTTP headers generated in users queries such as User-Agent, Cookies, etc.<\/p>\n

Using Vary: User-Agent might lead to ineffective caching. If the website is serving the Vary header with a directive which is not critical for the website\u2019s proper operation you would better exclude it from SuperCache.<\/p>\n

If the website is serving Vary: User-Agent header, but there is no website feature or content to vary for different browsers (User-Agent) you can exclude the User-Agent directive from SuperCache.<\/p>\n

You can exclude a specific directive of the Vary header under SuperCache settings\u00a0\u00bb Ignored Vary Headers.<\/p>\n

To test this feature through a console, you can change the User-Agent parameter in curl, e.g.:<\/p>\n

curl -I -A “MyUserAgent” http:\/\/cookies.goodexample.eu<\/p>\n

Note<\/strong>: If the website serves different content for mobile and desktop users and uses the User-Agent header to distinguish them, the User-Agent should not be added to the Ignored Vary Headers in SuperCache.<\/div>\n
back to the top\"back<\/a><\/div>\n
\n

Read more:<\/p>\n

SuperCache Manager by SuperHosting<\/a><\/p>\n

Advanced Settings in SuperCache Manager<\/a><\/p>\n

HTTP Headers<\/a><\/p>\n

HTTP Vary Header<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

When you fine tune\u00a0SuperCache and test its options, the special HTTP status headers generated will help you a lot.<\/p>\n","protected":false},"author":11,"comment_status":"closed","ping_status":"closed","template":"","format":"standard","meta":{"inline_featured_image":false,"_lmt_disableupdate":"","_lmt_disable":"no","footnotes":""},"ht-kb-category":[],"ht-kb-tag":[],"class_list":["post-9692","ht_kb","type-ht_kb","status-publish","format-standard","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t