A cache control header is missing or empty ошибка

loading a webpage i get this error:

A 'cache-control' header is missing or empty.

for favicon.ico resource.
My .htaccess is so configured:

<IfModule mod_headers.c>

    Header always set X-Content-Type-Options nosniff        
    Header unset Expires
    Header unset Pragma
    Header unset X-Powered-By

    <FilesMatch ".(php)$">
        Header set Cache-Control "no-cache" 
    </FilesMatch>
    
    <Files "favicon.ico">
        Header set Cache-Control max-age=31536000    
    </Files>
    
</IfModule>

How i can fix it?

  • .htaccess
  • caching

asked Jun 1, 2021 at 10:39

Marcello Impastato's user avatar

5

  • Maybe this page can help

    Jun 1, 2021 at 10:51

  • Try Cache-Control: public, max-age=31536000, immutable in 2nd block.

    Jun 2, 2021 at 7:50

  • @anubhava nothing. i have tried to put it in format for htaccess but not work (err 500) and tried in three lines separated and i continue to display that error.

    Jun 2, 2021 at 14:08

  • Is that your full .htaccess?

    Jun 2, 2021 at 16:18

  • only it for test.

    Jun 3, 2021 at 9:10

Как включить кэширование браузера для моего сайта? Я просто помещаю cache-control: public где-то в моем заголовке, как это?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
Cache-Control:public;
>

Я использую последнюю версию PHP, разработанную на последней версии XAMPP.

8 ответов


чтобы использовать Cache-control в HTML, вы используете мета-тег, например,

<meta http-equiv="Cache-control" content="public">

значение в поле «содержание» определяется как одно из четырех значений ниже.

информацию о Cache-Control заголовок выглядит следующим образом

HTTP 1.1. Допустимые значения = PUBLIC | PRIVATE | NO-CACHE / no-STORE.

Public — может кэшироваться в общедоступных общих кэшах.
Private — может кэшироваться только в частном кэше.
No-Cache — не может быть кэширован.
No-Store — может быть кэширован, но не архивирован.

директива CACHE-CONTROL: NO-CACHE указывает, что кэшированная информация не должна использоваться
и вместо этого запросы должны быть перенаправлены на исходный сервер. Эта директива имеет ту же семантику, что и PRAGMA:NO-CACHE.

клиенты должны включите PRAGMA: NO-CACHE и Cache-CONTROL: NO-CACHE, когда запрос no-cache отправляется на сервер, который не известен HTTP / 1.1 совместимый. Также см. EXPIRES.

Примечание: возможно, лучше указать команды кэша в HTTP, чем в мета-операторах, где они могут влиять больше, чем браузер, но прокси и другие посредники, которые могут кэшировать информацию.


вы можете установите заголовки в PHP использование:

<?php
  //set headers to NOT cache a page
  header("Cache-Control: no-cache, must-revalidate"); //HTTP 1.1
  header("Pragma: no-cache"); //HTTP 1.0
  header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past

  //or, if you DO want a file to cache, use:
  header("Cache-Control: max-age=2592000"); //30days (60sec * 60min * 24hours * 30days)

?>

обратите внимание, что точные используемые заголовки будут зависеть от ваших потребностей (и если вам нужно поддерживать HTTP 1.0 и/или HTTP 1.1)


Как я писал (в http://www.williamferreira.net/blog/2011/10/04/controle-de-cache-apache/) лучше всего использовать файл .htacces. Однако остерегайтесь времени, когда вы оставляете содержимое в кэше.

использование:

<FilesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>

где: 604800 = 7 дней

PS: Это можно использовать для сброса любого заголовка


страница в http://www.askapache.com/htaccess/apache-speed-cache-control.html предлагает использовать что-то вроде этого:

Добавить Заголовки Управления Кэшем

это входит в ваш корень .htaccess файл, но если у вас есть доступ к
файл httpd.conf, который лучше.

Этот код использует директиву FilesMatch и директиву Header для добавления заголовков управления кэшем в определенные файлы.

# 480 weeks
<FilesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=290304000, public"
</FilesMatch>

для сервера Apache, вы должны проверить mod_expires для установки истекает и заголовки управления кэшем.

кроме того, вы можете использовать заголовок директива для добавления управления кэшем самостоятельно:

Header set Cache-Control "max-age=290304000, public"

Это самый лучший .htaccess я использовал на мой сайт:

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

##Tweaks##
Header set X-Frame-Options SAMEORIGIN

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>
## EXPIRES CACHING ##

<IfModule mod_headers.c>
    Header set Connection keep-alive
    <filesmatch ".(ico|flv|gif|swf|eot|woff|otf|ttf|svg)$">
        Header set Cache-Control "max-age=2592000, public"
    </filesmatch>
    <filesmatch ".(jpg|jpeg|png)$">
        Header set Cache-Control "max-age=1209600, public"
    </filesmatch>
    # css and js should use private for proxy caching https://developers.google.com/speed/docs/best-practices/caching#LeverageProxyCaching
    <filesmatch ".(css)$">
        Header set Cache-Control "max-age=31536000, private"
    </filesmatch>
    <filesmatch ".(js)$">
        Header set Cache-Control "max-age=1209600, private"
    </filesmatch>
    <filesMatch ".(x?html?|php)$">
        Header set Cache-Control "max-age=600, private, must-revalidate"
      </filesMatch>
</IfModule>

OWASP рекомендует следующее:

по возможности убедитесь, что HTTP-заголовок cache-control установлен с no-cache, no-store, must-revalidate, private; и что HTTP-заголовок pragma установлен с no-cache.

<IfModule mod_headers.c>
    Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
    Header set Pragma "no-cache"
</IfModule>

тег meta cache control позволяет веб-издателям определять, как страницы должны обрабатываться кэшами. Они включают директивы для объявления того, что должно быть кэшируемым, что может храниться в кэшах, изменения механизма истечения срока действия, а также повторную проверку и
перезагрузите управления.

допустимые значения:

Public — может кэшироваться в общедоступных общих кэшах
Private-может быть кэширован только в private cache
no-Cache-не может быть кэширован
no-Store — может быть кэширован, но не архивируются

пожалуйста, будьте осторожны с чувствительностью к регистру. Добавьте следующий метатег в источник вашей веб-страницы. Разница в написании в конце тега заключается в том, что вы используете » /> = xml или «> = html.

    <meta http-equiv="Cache-control" content="public">
    <meta http-equiv="Cache-control" content="private">
    <meta http-equiv="Cache-control" content="no-cache">
    <meta http-equiv="Cache-control" content="no-store">

источник-> метатеги


The Cache-Control HTTP header field holds directives (instructions) — in both requests and responses — that control caching in browsers and shared caches (e.g. Proxies, CDNs).

Header type Request header,
Response header
Forbidden header name no
CORS-safelisted response header yes

Syntax

Caching directives follow the validation rules below:

  • Caching directives are case-insensitive. However, lowercase is recommended because some implementations do not recognize uppercase directives.
  • Multiple directives are comma-separated.
  • Some directives have an optional argument.

Cache directives

The following table lists the standard Cache-Control directives:

Request Response
max-age max-age
max-stale
min-fresh
s-maxage
no-cache no-cache
no-store no-store
no-transform no-transform
only-if-cached
must-revalidate
proxy-revalidate
must-understand
private
public
immutable
stale-while-revalidate
stale-if-error stale-if-error

Note: Check the compatibility table for their support; user agents that don’t recognize them should ignore them.

Vocabulary

This section defines the terms used in this document, some of which are from the specification.

(HTTP) cache

Implementation that holds requests and responses for reusing in subsequent requests. It can be either a shared cache or a private cache.

Shared cache

Cache that exists between the origin server and clients (e.g. Proxy, CDN). It stores a single response and reuses it with multiple users — so developers should avoid storing personalized contents to be cached in the shared cache.

Private cache

Cache that exists in the client. It is also called local cache or browser cache. It can store and reuse personalized content for a single user.

Store response

Store a response in caches when the response is cacheable. However, the cached response is not always reused as-is. (Usually, «cache» means storing a response.)

Reuse response

Reuse cached responses for subsequent requests.

Revalidate response

Ask the origin server whether or not the stored response is still fresh. Usually, the revalidation is done through a conditional request.

Fresh response

Indicates that the response is fresh. This usually means the response can be reused for subsequent requests, depending on request directives.

Stale response

Indicates that the response is a stale response. This usually means the response can’t be reused as-is. Cache storage isn’t required to remove stale responses immediately because revalidation could change the response from being stale to being fresh again.

Age

The time since a response was generated. It is a criterion for whether a response is fresh or stale.

Directives

This section lists directives that affect caching — both response directives and request directives.

Response Directives

max-age

The max-age=N response directive indicates that the response remains fresh until N seconds after the response is generated.

Cache-Control: max-age=604800

Indicates that caches can store this response and reuse it for subsequent requests while it’s fresh.

Note that max-age is not the elapsed time since the response was received; it is the elapsed time since the response was generated on the origin server.
So if the other cache(s) — on the network route taken by the response — store the response for 100 seconds (indicated using the Age response header field), the browser cache would deduct 100 seconds from its freshness lifetime.

Cache-Control: max-age=604800
Age: 100

s-maxage

The s-maxage response directive also indicates how long the response is fresh for (similar to max-age) — but it is specific to shared caches, and they will ignore max-age when it is present.

Cache-Control: s-maxage=604800

no-cache

The no-cache response directive indicates that the response can be stored in caches, but the response must be validated with the origin server before each reuse, even when the cache is disconnected from the origin server.

If you want caches to always check for content updates while reusing stored content, no-cache is the directive to use. It does this by requiring caches to revalidate each request with the origin server.

Note that no-cache does not mean «don’t cache». no-cache allows caches to store a response but requires them to revalidate it before reuse. If the sense of «don’t cache» that you want is actually «don’t store», then no-store is the directive to use.

must-revalidate

The must-revalidate response directive indicates that the response can be stored in caches and can be reused while fresh. If the response becomes stale, it must be validated with the origin server before reuse.

Typically, must-revalidate is used with max-age.

Cache-Control: max-age=604800, must-revalidate

HTTP allows caches to reuse stale responses when they are disconnected from the origin server. must-revalidate is a way to prevent this from happening — either the stored response is revalidated with the origin server or a 504 (Gateway Timeout) response is generated.

proxy-revalidate

The proxy-revalidate response directive is the equivalent of must-revalidate, but specifically for shared caches only.

no-store

The no-store response directive indicates that any caches of any kind (private or shared) should not store this response.

private

The private response directive indicates that the response can be stored only in a private cache (e.g. local caches in browsers).

You should add the private directive for user-personalized content, especially for responses received after login and for sessions managed via cookies.

If you forget to add private to a response with personalized content, then that response can be stored in a shared cache and end up being reused for multiple users, which can cause personal information to leak.

public

The public response directive indicates that the response can be stored in a shared cache. Responses for requests with Authorization header fields must not be stored in a shared cache; however, the public directive will cause such responses to be stored in a shared cache.

In general, when pages are under Basic Auth or Digest Auth, the browser sends requests with the Authorization header. This means that the response is access-controlled for restricted users (who have accounts), and it’s fundamentally not shared-cacheable, even if it has max-age.

You can use the public directive to unlock that restriction.

Cache-Control: public, max-age=604800

Note that s-maxage or must-revalidate also unlock that restriction.

If a request doesn’t have an Authorization header, or you are already using s-maxage or must-revalidate in the response, then you don’t need to use public.

must-understand

The must-understand response directive indicates that a cache should store the response only if it understands the requirements for caching based on status code.

must-understand should be coupled with no-store for fallback behavior.

Cache-Control: must-understand, no-store

If a cache doesn’t support must-understand, it will be ignored. If no-store is also present, the response isn’t stored.

If a cache supports must-understand, it stores the response with an understanding of cache requirements based on its status code.

no-transform

Some intermediaries transform content for various reasons. For example, some convert images to reduce transfer size. In some cases, this is undesirable for the content provider.

no-transform indicates that any intermediary (regardless of whether it implements a cache) shouldn’t transform the response contents.

Note: Google’s Web Light is one kind of such an intermediary. It converts images to minimize data for a cache store or slow connection and supports no-transform as an opt-out option.

immutable

The immutable response directive indicates that the response will not be updated while it’s fresh.

Cache-Control: public, max-age=604800, immutable

A modern best practice for static resources is to include version/hashes in their URLs, while never modifying the resources — but instead, when necessary, updating the resources with newer versions that have new version-numbers/hashes, so that their URLs are different. That’s called the cache-busting pattern.

<script src=https://example.com/react.0.0.0.js></script>

When a user reloads the browser, the browser will send conditional requests for validating to the origin server. But it’s not necessary to revalidate those kinds of static resources even when a user reloads the browser, because they’re never modified.
immutable tells a cache that the response is immutable while it’s fresh and avoids those kinds of unnecessary conditional requests to the server.

When you use a cache-busting pattern for resources and apply them to a long max-age, you can also add immutable to avoid revalidation.

stale-while-revalidate

The stale-while-revalidate response directive indicates that the cache could reuse a stale response while it revalidates it to a cache.

Cache-Control: max-age=604800, stale-while-revalidate=86400

In the example above, the response is fresh for 7 days (604800s).
After 7 days it becomes stale, but the cache is allowed to reuse it for any requests that are made in the following day (86400s), provided that they revalidate the response in the background.

Revalidation will make the cache be fresh again, so it appears to clients that it was always fresh during that period — effectively hiding the latency penalty of revalidation from them.

If no request happened during that period, the cache became stale and the next request will revalidate normally.

stale-if-error

The stale-if-error response directive indicates that the cache can reuse a stale response when an upstream server generates an error, or when the error is generated locally. Here, an error is considered any response with a status code of 500, 502, 503, or 504.

Cache-Control: max-age=604800, stale-if-error=86400

In the example above, the response is fresh for 7 days (604800s). Afterwards, it becomes stale, but can be used for an extra 1 day (86400s) when an error is encountered.

After the stale-if-error period passes, the client will receive any error generated.

Request Directives

no-cache

The no-cache request directive asks caches to validate the response with the origin server before reuse.

no-cache allows clients to request the most up-to-date response even if the cache has a fresh response.

Browsers usually add no-cache to requests when users are force reloading a page.

no-store

The no-store request directive allows a client to request that caches refrain from storing the request and corresponding response — even if the origin server’s response could be stored.

Note that the major browsers do not support requests with no-store.

max-age

The max-age=N request directive indicates that the client allows a stored response that is generated on the origin server within N seconds — where N may be any non-negative integer (including 0).

Cache-Control: max-age=3600

In the case above, if the response with Cache-Control: max-age=604800 was generated more than 3 hours ago (calculated from max-age and the Age header), the cache couldn’t reuse that response.

Many browsers use this directive for reloading, as explained below.

max-age=0 is a workaround for no-cache, because many old (HTTP/1.0) cache implementations don’t support no-cache. Recently browsers are still using max-age=0 in «reloading» — for backward compatibility — and alternatively using no-cache to cause a «force reloading».

If the max-age value isn’t non-negative (for example, -1) or isn’t an integer (for example, 3599.99), then the caching behavior is undefined. However, the Calculating Freshness Lifetime section of the HTTP specification states:

Caches are encouraged to consider responses that have invalid freshness information to be stale.

In other words, for any max-age value that isn’t an integer or isn’t non-negative, the caching behavior that’s encouraged is to treat the value as if it were 0.

max-stale

The max-stale=N request directive indicates that the client allows a stored response that is stale within N seconds.

Cache-Control: max-stale=3600

In the case above, if the response with Cache-Control: max-age=604800 was generated more than 3 hours ago (calculated from max-age and the Age header), the cache couldn’t reuse that response.

Clients can use this header when the origin server is down or too slow and can accept cached responses from caches even if they are a bit old.

Note that the major browsers do not support requests with max-stale.

min-fresh

The min-fresh=N request directive indicates that the client allows a stored response that is fresh for at least N seconds.

Cache-Control: min-fresh=600

In the case above, if the response with Cache-Control: max-age=3600 was stored in caches 51 minutes ago, the cache couldn’t reuse that response.

Clients can use this header when the user requires the response to not only be fresh, but also requires that it won’t be updated for a period of time.

Note that the major browsers do not support requests with min-fresh.

no-transform

Same meaning that no-transform has for a response, but for a request instead.

only-if-cached

The client indicates that cache should obtain an already-cached response. If a cache has stored a response, it’s reused.

Use Cases

Preventing storing

If you don’t want a response stored in caches, use the no-store directive.

Note that no-cache means «it can be stored but don’t reuse before validating» — so it’s not for preventing a response from being stored.

In theory, if directives are conflicted, the most restrictive directive should be honored. So the example below is basically meaningless because private, no-cache, max-age=0 and must-revalidate conflict with no-store.

# conflicted
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate

# equivalent to
Cache-Control: no-store

Caching static assets with «cache busting»

When you build static assets with versioning/hashing mechanisms, adding a version/hash to the filename or query string is a good way to manage caching.

For example:

<!-- index.html -->
<script src="/assets/react.min.js"></script>
<img src="/assets/hero.png" width="900" height="400" />

The React library version will change when you update the library, and hero.png will also change when you edit the picture. So those are hard to store in a cache with max-age.

In such a case, you could address the caching needs by using a specific, numbered version of the library, and including the hash of the picture in its URL.

<!-- index.html -->
<script src="/assets/react.0.0.0min.js"></script>
<img src="/assets/hero.png?hash=deadbeef" width="900" height="400" />

You can add a long max-age value and immutable because the content will never change.

# /assets/*
Cache-Control: max-age=31536000, immutable

When you update the library or edit the picture, new content should have a new URL, and caches aren’t reused. That is called the «cache busting» pattern.

Use a no-cache to make sure that the HTML response itself is not cached. no-cache could cause revalidation, and the client will correctly receive a new version of the HTML response and static assets.

# /index.html
Cache-Control: no-cache

Note: If index.html is controlled under Basic Authentication or Digest Authentication, files under /assets are not stored in the shared cache. If /assets/ files are suitable for storing in a shared cache, you also need one of public, s-maxage or must-revalidate.

Up-to-date contents always

For content that’s generated dynamically, or that’s static but updated often, you want a user to always receive the most up-to-date version.

If you don’t add a Cache-Control header because the response is not intended to be cached, that could cause an unexpected result. Cache storage is allowed to cache it heuristically — so if you have any requirements on caching, you should always indicate them explicitly, in the Cache-Control header.

Adding no-cache to the response causes revalidation to the server, so you can serve a fresh response every time — or if the client already has a new one, just respond 304 Not Modified.

Most HTTP/1.0 caches don’t support no-cache directives, so historically max-age=0 was used as a workaround. But only max-age=0 could cause a stale response to be reused when caches disconnected from the origin server. must-revalidate addresses that. That’s why the example below is equivalent to no-cache.

Cache-Control: max-age=0, must-revalidate

But for now, you can simply use no-cache instead.

Clearing an already-stored cache

Unfortunately, there are no cache directives for clearing already-stored responses from caches.

Imagine that clients/caches store a fresh response for a path, with no request flight to the server. There is nothing a server could do to that path.

Alternatively, Clear-Site-Data can clear a browser cache for a site. But be careful: that clears every stored response for a site — and only in browsers, not for a shared cache.

Specifications

Specification
HTTP Caching
# field.cache-control
HTTP Immutable Responses
# the-immutable-cache-control-extension

Browser compatibility

BCD tables only load in the browser

See also

  • Что такое cache-control?
    • Основные принципы использования заголовка Cache-Control
    • Что такое max-age?
    • Применение max-age
    • Директивы кэширования
    • public
    • private
    • no-store
    • Типы файлов
    • Какие типы файлов должны храниться в кэше?
    • Что следует учесть
    • Как добавить Cache-Control на сайт
    • Файл .htaccess
    • Пример кода файла .htaccess
    • Конфигурация Apache http.conf
    • NGINX
    • Litespeed

Cache-Control — это HTTP-заголовок, который определяет количество времени и способ htaccess кэширования файла:

Что такое cache-control?

В этой статье мы расскажем, как использовать Cache-Control. Большинство современных сайтов используют Cache-Control для управления кэшированием браузеров.

Заголовок Cache-Control определяет количество времени, которое файл должен находиться в кэше, и метод кэширования:

Cache-Control: max-age=2592000, public

При обращении к файлу через браузер также извлекаются HTTP-заголовки. Когда заголовок Cache-Control включен, браузер будет его учитывать.

Если браузер видит, что файл должен храниться в течение пяти минут, он будет оставаться в кэше браузера в течение этого времени. И этот файл не должен обновляться при его повторном вызове:

Основные принципы использования заголовка Cache-Control

В качестве примера можно привести логотип сайта. Если посетитель заходит на одну страниц ресурса, он загружает логотип. Если пользователь переходит на другую страницу, изображение логотипа не будет загружаться снова. Вместо этого будет использоваться кэширование через htaccess.

max-age определяет время, в течение которого файл должен храниться в кэше.

Директива ответа max-age указывает, что ответ следует считать устаревшим после того, как проходит больше времени, чем заданное количество секунд.

Часть заголовка max-age выглядит следующим образом:

Значение max-age задается в секундах.

Часто используемые значения для max-age:

  • Одна минута: max-age=60;
  • Один час: max-age=3600;
  • Один день: max-age=86400;
  • Одна неделя: max-age=604800;
  • Один месяц: max-age=2628000;
  • Один год: max-age=31536000.

При применении max-age для определения времени, которое файл должен храниться в кэше, следует учитывать тип этого файла и то, как он используется.

Часть директивы кэширования в браузере htaccess приведенного выше заголовка выглядит следующим образом:

Директива приведенного выше заголовка Cache-Control объявляет «public«. Это означает, что файл может кэшироваться публично (в отличие от случая, если бы это был private файл).

По умолчанию, большинство элементов считаются публично кэшируемыми (могут кэшироваться), но существуют случаи, когда такое поведение нежелательно: для конфиденциальных документов, для контента, предназначенного для конкретного пользователя, и т.д.

Мы рассмотрим три основные директивы Cache-Control:

  • public;
  • private;
  • no-store.

Директива «public» означает, что любой человек может осуществлять кэширование файлов htaccess на любом уровне.

Официальная спецификация определяет ее следующим образом:

Директива «public» указывает на то, что ответ может сохраняться где угодно в кэше, даже если он является некэшируемым или кэшируемым только в частном кэше.

Если вы хотите использовать кэширование для ускорения загрузки страницы, и этот ресурс не является частным, то нужно применить директиву public.

Директива private означает, что ресурс предназначается только для конкретного пользователя. В качестве примера можно привести страницу Twitter. Когда вы заходите в Twitter, вы видите одно, а другой человек, открывающий тот же URL-адрес, видит другое содержимое. Даже если информация на этой странице общедоступна, она «специфична» для конкретного человека.

Официальная спецификация определяет ее следующим образом:

Директива «private» указывает, что ответ предназначен для одного пользователя и не должен сохраняться в общедоступном кэше. Частный кэш может сохранять ответ и повторно использовать его для последующих запросов, даже если ответ является некэшируемым.

Если я зайду на Twitter.com, а затем обновлю страницу, некоторые элементы будут сохранены для меня с помощью кэширования и сжатие htaccess, а для вас нет. Если вы зайдете на Twitter.com и обновите страницу, некоторые элементы будут сохранены для вас в кэше, а для меня нет.

Директива no-store является самым категоричным запретом на кэширование. Официальная спецификация определяет ее следующим образом:

Директива «no-store» указывает на то, что в кэше не должны сохраняться части ни запроса, ни ответа. Эта директива применяется как для частного, так и для публичного кэша.

Еще раз отмечу, что само по себе это ничего не гарантирует.

Два вопроса, которые должен задать себе веб-мастер:

  • Какие типы файлов нужно хранить с помощью кэширования файлов htaccess?
  • Как долго их нужно хранить в кэше?

Я хотел бы отметить следующие типы файлов:

  • ИзображенияPNG, JPG, GIF и другие. Изображения практически не меняются, поэтому они могут храниться в кэше длительное время (год);
  • CSS файлы — изменяются чаще, чем другие файлы, для их хранения может потребоваться более короткий период времени (неделя или месяц);
  • ICO (Favicon) — редко меняются (год);
  • JSкод JavaScript не изменяются слишком часто, поэтому для них можно задать средний период хранения (месяц).

Только вы можете определить, какие инструкции больше всего подходят для вашего сайта. Если вы собираетесь изменить какой-либо ресурс (например, файл CSS), и этот ресурс кэшируется в браузере htaccess, то стоит подумать над тем, чтобы изменить имя файла. Тогда обновленный файл CSS будет просмотрен всеми пользователями. Это называется URL-дактилоскопией.

Благодаря уникальному имени пользователи будут загружать новый (не кэшированный) вариант ресурса. Например, если ваш файл CSS имеет имя «main.css«, вместо этого можно назвать его «main_1.css«. В следующий раз, когда снова измените его, назовите «main_2.css«. Это полезно для файлов, которые изменяются через определенные периоды времени.

Cache -Control добавляется к файлам точно так же, как любой другой заголовок на вашем сервере. В этой статье мы говорим о заголовке Cache-Control. Так как его добавить? Это зависит от вашего веб-сервера. Мы рассмотрим наиболее распространенные сценарии.

Большинство использует для добавления заголовков файл .htaccess.

Общий код для установки заголовка Cache-Control с помощью файла .htaccess:

Header set Cache-Control "max-age=2628000, public"

Но приведенный выше код не позволяет задавать различные инструкции кэширования сайта htaccess для различных типов файлов.

Чтобы применить разные заголовки Cache-Control к различным типам файлов, мы будем использовать:

# One month for most static assets
<filesMatch ".(css|jpg|jpeg|png|gif|js|ico)$">
Header set Cache-Control "max-age=2628000, public"
</filesMatch>

Приведенный выше код означает следующее:

«Если тип файла CSS, JPEG, JPG, PNG, GIF, JS или ICO, применить к нему следующий заголовок«.

Предположим, что мы хотим изменить время кэширования изображений на один год, но оставить для файлов CSS и JS срок хранения один месяц.

Мы можем добавить в файл .htaccess следующий код:

# One year for image files
<filesMatch ".(jpg|jpeg|png|gif|ico)$">
Header set Cache-Control "max-age=31536000, public"
</filesMatch>
# One month for css and js
<filesMatch ".(css|js)$">
Header set Cache-Control "max-age=2628000, public"
</filesMatch>

Приведенный выше код состоит из двух блоков: один для изображений и один для CSS и JS-файлов. У нас может быть несколько блоков в файле .htaccess.

Более быстрым и предпочтительным способом является установка заголовков с помощью конфигурационного файла. Примеры кода, приведенные выше для htaccess кэширования, будут работать и здесь.

Используйте сочетание filesMatch и Header, чтобы создать отдельные инструкции для конкретных типов файлов (примеры кода для файла .htaccess подходят).

Используя директивы expires, можно добавить инструкции кэширования в блоки сервера или местоположения:

location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}

Приведенный выше код задает инструкции кэширования для каждого из типов файлов, перечисленных в первой строке. Эти типы файлов могут быть добавлены или удалены. Также можно добавить несколько блоков для более гибкой настройки.

Если есть лицензия на несколько процессоров, то вы должны иметь доступ к расширенным директивам кэширования через онлайн-конфигурацию.

Если у вас нет лицензии, то необходимо будет использовать кэширование сайта htaccess. Приведенные выше инструкции для использования в .htaccess подходят также и для серверов Litespeed.

i have set up an nginx server in ubuntu as a reverse proxy cache server.My application code resides in /var/www/myapp folder.

following are the configuration i have given in

server {
        listen   80; ## listen for ipv4; this line is default and implied
        root /var/www/;
        index index.html index.htm;

        # Make site accessible from http://localhost/
        server_name localhost;

        location / {

            proxy_pass         http://127.0.0.1:8080/;
            rewrite ^([^.]*[^/])$ $1/ permanent;
            add_header X-Cache-Status $upstream_cache_status;
        }

        location /doc/ {
                alias /usr/share/doc/;
                autoindex on;
                allow 127.0.0.1;
                deny all;
        }
    }

is the content of my nginx/sites-available/default file

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
        worker_connections 1024 ;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

         server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";

         gzip_vary on;
          gzip_proxied any;
         gzip_comp_level 6;
         gzip_buffers 16 8k;
         gzip_http_version 1.1;
         gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;


        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;

        proxy_cache_path  /var/www/cache levels=1:2 keys_zone=my-cache:8m max_size=1000m inactive=600m;
        proxy_temp_path /var/www/cache/tmp;
        proxy_cache my-cache;
        proxy_cache_valid  200 302  60m;
        proxy_cache_valid  404      1m;

}

is the content of my nginx/nginx.conf file

Nginx is caching the files under /var/www/cache directory

But when i check the header response of my page http://mydomain.com/myapp in firefox using firebug it shows

Cache-Control   no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection  keep-alive
Content-Encoding    gzip
Content-Length  3817
Content-Type    text/html; charset=utf-8
Date    Fri, 29 Mar 2013 10:19:23 GMT
Expires Thu, 19 Nov 1981 08:52:00 GMT
Pragma  no-cache
Server  nginx/1.1.19
Vary    Accept-Encoding
X-Cache-Status  MISS
X-Powered-By    PHP/5.3.10-1ubuntu3.6

X-Cache-Status is MISS. Why it is not served from the cache?

Cache-Control are HTTP cache headers that holds instructions for caching for requests and responses. It is used to defines how a resource is cached, where it’s cached and its maximum age before expiring. When you visit a website, your browser will save images and website data in a store called the cache. When you revisit the same website again, cache-control sets the rules that determine whether your resources loaded from your local cache or if the browser should send a request to the server for fresh resources.

For better understanding of how the browser renders pages quickly using the cache, you need to know about browser caching and HTTP headers.

What is browser caching?

Browser caching is a temporary storage of Web documents, such as images, media and pages. The intend behind this is to help reduce bandwidth. It is used to increase a users browsing speed by locally downloading Web page components to the browser cache. When you revisit that Web page, there is no need to re-download such components. This results in a faster Web page load. Browser will save those resources only for a specific period of time called TTL. Once the TTL has expired, the browser will have to reach out to the server again and download a fresh copy of the resource.

What are HTTP headers?

HTTP headers are the core part of HTTP requests and responses and provide required information about the request or response. All the headers are case-insensitive, headers fields are separated by colon, key-value pairs in clear-text string format. These headers contain information about each communication. For example, the request header contains, information on what resource is being requested, which browser the client is using and what data formats the client will accept. While response headers contain information on, whether the request was successfully fulfilled and the language and format of any resources in the body of the response.

The cache-control header is broken up into directives. You can see the cache-control header of https://google.com with the following command:

curl -I https://google.com

You should get the following output:

HTTP/1.1 301 Moved Permanently
Location: https://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Fri, 05 Jun 2020 03:03:10 GMT
Expires: Sun, 05 Jul 2020 03:03:10 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 220
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Alt-Svc: h3-27=":443"; ma=2592000,h3-25=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q049=":443"; ma=2592000,h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"

As you can see, the part to the left of the colon is cache-control and the value is on the right of the colon, and there can be one or several comma-separated values for cache control. These values are called directives, and they dictate who can cache a resource as well as how long those resources can be cached before they must be updated.

The most common cache-control headers are detailed below:

Cache-Control: Public

This directive indicates that the response may be stored by any cache, even if the response is normally non-cacheable.

Cache-Control: Private

This directive indicates that the response can only be cached by the browser that is accessing the file. It can not be cached by an intermediary agent such as proxy or CDN.

Cache-Control: Max-Age

This directive indicates that the maximum amount of time a resource is considered fresh. In other words how many seconds a resource can be served from cache after it’s been downloaded. For example, if the max age is set to 3600 means that the returned resource is valid for 3600 seconds, after which the browser has to request a newer version.

You can also use a technique developed by some assets builders tools, like Webpack or Gulp to force the browser to download a new version of the needed file. This will precompiled each file on the server and add hash sums to the file names, such as “app-72420c47cc.css”. So, after next the deployment, you will get a new version of the file.

Cache-Control: No-Cache

This directive indicates that a browser may cache a response, but must first submit a validation request to an origin server. This directive is not effective in preventing caches from storing your response. It allows you to cache but subsequence response or any subsequence response for similar data the client needs to check with the browser whether that resource has changed or not. Only if the resource has not changed then the client serves the cache which is stored.

If you apply the technique you learned in the previous section in html files, you will never get new links for your css, js, or image files until you force a reload.

It is recommended to use Cache-Control: no-cache to html files to validate resources on the server before use it from the cache.

Cache-Control: No-Store

This directive indicates that the response should never be cached, For example, banking details you would not want to be stored in any browser cache. For those kinds of purposes, you can use no-store.

Configure Cache-Contol Headers for Apache and Nginx Webserver

In this section, we will show you how to set the HTTP Cache-Control header in Apache and Nginx.

Apache

For the Apache web server, you will need edit your website virtual host configuration file in order to implement the HTTP Cache-Control header, for example:

nano /etc/apache2/sites-enabled/webdock.conf

Add the following contents:

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
    Header set Cache-Control "max-age=3600, public"
</filesMatch>

If you want to enable Cache-Control for all files, add Header set line outside the filesMatch block.

As you can see, we set the Cache-Control header’s max-age to 3600 seconds and to public for the listed files.

This can also be set in a .htaccess file in any directory below your web root. If you are using SSL you should consider adding this to the ssl version of your  virtual host configuration, which is also placed in /etc/apache2/sites-enabled/

Nginx

For the Nginx web server, you will need to edit your website virtual host configuration file to implement the HTTP Cache-Control header, for example:

nano /etc/nginx/sites-enabled/webdock

Add the following contents:

location ~* .(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$ {
    expires 1h;
    add_header Cache-Control "public, no-transform";
}

If you want to enable Cache-Control for all files, add a add_header line without the enclosing location block, as what the location block does is specify specific filetypes you are targeting with your directives (ico,pdf,flv etc.).

Recommended Settings

We recommend the following settings for all cacheable resources:

  1. For js,css, and image files, set Cache-Control: public, max-age=31536000, no Etag, no Last-Modified settings.

    Apache:

    <filesMatch ".(js|css|jpg|jpeg|png|gif|js|css|ico|swf)$">
                    Header set Cache-Control "max-age=31536000, public"
                    Header unset Last-Modified
                    Header unset ETag
                </filesMatch>

    Nginx:

    location ~* .(js|css|jpg|jpeg|png|gif|js|css|ico|swf)$ {
                    expires 1y;
                    etag off;
                    if_modified_since off;
                    add_header Cache-Control "public, no-transform";
                }
                
  2. Set the Last-Modified date to the last time the resource was changed.(Note: This already happens by default in Nginx or Apache)
     
  3. If you need precise control over when resources are invalidated we recommend using a URL fingerprinting or versioning technique.
    For example, when you do changes to one css file, you should change name to be sure that the updated file will be seen by all because file is cached.This is called URL fingerprinting.
     
  4. For html files, use Cache-Control: no-cache, and Etag.

    Apache:

    <filesMatch ".(html$">
            Header set Cache-Control "no-cache"
        </filesMatch>

    Nginx:

    location ~* .(html)$ {
            etag on;
            add_header Cache-Control "no-cache";
        }
        
  5. Use Webpack, Gulp or other tools and add unique hash digits to your js, css and image files. (For example, app-67ce7f3483.css). This will force the browser to download a new version of the needed file.

    If you want to read more about Webpack, you can check out these guides: https://webpack.js.org/guides/getting-started/

The following — mildly daunting — chart may help with deciding what specific cache directives should be added to a resource:

cache_chart.png

Etag (Entity tag)

The Etag also called HTTP response header is a cache validators used to determine whether a component in the browser’s cache matches one on the origin server. This will helps to improve loading times since if the resource can be retrieved from local cache, the browser does not need to make an additional request to the server.

The ETag or entity tag is part of HTTP, the protocol for the World Wide Web. It is one of several mechanisms that HTTP provides for web cache validation, and which allows a client to make conditional requests. This allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed. ETags can also be used for optimistic concurrency control, as a way to help prevent simultaneous updates of a resource from overwriting each other.

An ETag is an opaque identifier assigned by a web server to a specific version of a resource found at a URL. If the resource content at that URL ever changes, a new and different ETag is assigned. Used in this manner ETags are similar to fingerprints, and they can be quickly compared to determine whether two versions of a resource are the same. Comparing ETags only makes sense with respect to one URL—ETags for resources obtained from different URLs may or may not be equal, so no meaning can be inferred from their comparison.

Configure Etag in Nginx or Apache for a Resource

Etags also called Entity Tags is another way to treat 304 replies. 304 responses are a way for the web server to tell the user that the latest version of the cache is the version it has, even though the cache time may expire. There is not need to access the file again as it is a waste of time and bandwidth in this situation.

The way it works it that when a browser requests a page that they have already accessed in the past, the browser will send, for example, an HTTP request header in the If-Modified-Since header with the cache date. It basically means «Hey web server, I have a copy of this file I’m asking you for, but it’s 10:15 AM from 1 July 2020, Is that okay to use or is there a newer version of this page available?» If there is a newer file, the web server will send that one to the browser, and if not just tell the browser to use the one it already has.

Etags have the following Advantages :

  • Effective filtering.
  • Quicker loading time.
  • Lower disk load.
  • Lower bandwidth usage.

Neverthless the utility of ETags depends on implementation and this can result in some problems:

  • Slower load times and caching the same resource multiple times
  • Higher server load and used bandwidth.

The whole point of using ETags is that they are intended to give us a more precise indication as to whether a file has changed, rather than merely basing it on a timestamp. Etag role is to tell browser if file has been updated or not, so if Etag is not present the browser always will act like file has been changed and will not use caches. ETag can be better in single server than in load balancing servers because if the Etags is not matched with the other server the user will not get the fast response of Etag!

Configure Etags in Apache

By default, ETags is enabled in Apache web server. If you want to check if ETags is enabled, run this command:

curl -I localhost

You should see that ETags is enabled in the following output:

HTTP/1.1 200 OK
Date: Wed, 01 Jul 2020 09:00:27 GMT
Server: Apache/2.4.7 (Ubuntu)
Last-Modified: Mon, 03 Feb 2020 14:55:14 GMT
ETag: "2cf6-59dad1c5a32cd"
Accept-Ranges: bytes
Content-Length: 11510
Vary: Accept-Encoding
Content-Type: text/html

You can also disable the ETags completely from your system and leave the caching to cache control headers.

You can disable ETags by editing the Apache default confoguration file:

nano /etc/apache2/apache2.conf

Add the following lines inside your default web root directory section:

Header unset Etag
FileETag none

Save and close the file then restart your Apache service to apply the changes:

systemctl restart apache2

If you do not have access to SSH on your server then you can edit the .htaccess file to disable ETags.

nano .htaccess

Add the following lines:

Header unset Etag
FileETag none

Save and close the file when you are finished.

You can also verify whether ETags is disabled or not with the following command:

curl -I localhost

You can not see any Etags header in the following output:

HTTP/1.1 200 OK
Date: Wed, 01 Jul 2020 09:01:11 GMT
Server: Apache/2.4.7 (Ubuntu)
Last-Modified: Mon, 03 Feb 2020 14:55:14 GMT
Accept-Ranges: bytes
Content-Length: 11510
Vary: Accept-Encoding
Content-Type: text/html

Configure Etags in Nginx

By default, Nginx also activates Etags once the cache headers are set. So, to be sure if Etag is enabled run this command:

curl -I localhost

You should see that ETags is enabled in the following output:

HTTP/1.1 200 OK
    Server: nginx
    Date: Thu, 10 Sep 2020 18:55:02 GMT
    Content-Type: application/octet-stream
    Content-Length: 1024
    Last-Modified: Thu, 10 Sep 2020 18:50:29 GMT
    Connection: keep-alive
    ETag: "5f5a7575-400"
    Expires: Thu, 10 Sep 2020 19:55:02 GMT
    Cache-Control: max-age=3600
    Cache-Control: public, no-transform
    Accept-Ranges: bytes 

You can also disable the ETags completely from your system and leave the caching to cache control headers.

You can disable ETags by editing the Nginx default confoguration file:

nano /etc/nginx/sites-enabled/webdock

Add «etag off;» on the lines you have added to enable cache-headers:

location ~* .(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$ {
    expires 1h;
    etag off;
    add_header Cache-Control "public, no-transform";
}

Save and close the file then restart your Apache service to apply the changes:

systemctl restart nginx

You can also check if ETags was successfully disable by running this command:

curl -I localhost

You can not see any Etags header in the following output:

HTTP/1.1 200 OK
    Server: nginx
    Date: Thu, 10 Sep 2020 19:02:08 GMT
    Content-Type: application/octet-stream
    Content-Length: 1024
    Last-Modified: Thu, 10 Sep 2020 18:50:29 GMT
    Connection: keep-alive
    Expires: Thu, 10 Sep 2020 20:02:08 GMT
    Cache-Control: max-age=3600
    Cache-Control: public, no-transform
    Accept-Ranges: bytes    

Security Headers

Now that you have read all about cache headers, we suggest you check out our companion article: How to configure Security Headers in Nginx and Apache

Conclusion

We hope this article was helpful to you, if you have any questions please don’t heasitate to leave a  comment.

  • Home
  • Forum
  • WEB DESIGN chat for Xara products
  • Xara web design chat
  • A ‘cache-control’ header is missing or empty.

  1. 04 June 2023, 02:10 PM


    #1

    Default A ‘cache-control’ header is missing or empty.

    Not sure why my website developed in Xara Web Designer+ shows this error when inspecting the site in the Edge Browser. I saw a thread, auto-cache, that Alcorn made some suggestions. But due to my inexperience, it was difficult to understand. Any help to resolve this issue would be much appreciated.


  2. 04 June 2023, 03:04 PM


    #2

    Default Re: A ‘cache-control’ header is missing or empty.

    Quote Originally Posted by klowetx
    View Post

    Not sure why my website developed in Xara Web Designer+ shows this error when inspecting the site in the Edge Browser. I saw a thread, auto-cache, that Alcorn made some suggestions. But due to my inexperience, it was difficult to understand. Any help to resolve this issue would be much appreciated.

    klowetx, in a nutshell, Xara renders HTML code that does not care about caching. That task is down to how & where you are serving your pages.

    Before HTML5 you could add a caching <meta> Tag into your website head. You could try: <meta http-equiv=»Cache-control» content=»public»>, but with no guarantees. It may fool Edge but might be doing nothing.

    What is far better is to add a .htaccess file into the root folder of your website. Xara cannot do this for you although it does allow you to ‘Explore web space’ through its Publish > Settings.
    Normally, you would access the root folder through some FTP client.

    Another approach is to hook into a free Cloudflare service, https://www.cloudflare.com/en-gb/abo…tion/?pr=asas1, where the cache-control is covered by Cloudflare’s CDN servers instead.

    Acorn

    Acorn — installed and active Xara software: Cloud+/Pro+, XDPXv18 , XWDPv12/v15, XPGDv10, X3D7, Xara Xtreme 5, and others back through time (to CC’s Artworks).
    Technical remediation and consultancy for your web designs. TG Nuggets you might like. Report faults: Magix; Xara Cloud+/Pro+


 

Tags for this Thread

Bookmarks

Bookmarks


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
  • BB code is On
  • Smilies are On
  • [IMG] code is Off
  • [VIDEO] code is Off
  • HTML code is Off

Forum Rules

loading a webpage i get this error:

A 'cache-control' header is missing or empty.

for favicon.ico resource.
My .htaccess is so configured:

<IfModule mod_headers.c>

    Header always set X-Content-Type-Options nosniff        
    Header unset Expires
    Header unset Pragma
    Header unset X-Powered-By

    <FilesMatch ".(php)$">
        Header set Cache-Control "no-cache" 
    </FilesMatch>
    
    <Files "favicon.ico">
        Header set Cache-Control max-age=31536000    
    </Files>
    
</IfModule>

How i can fix it?

  • .htaccess
  • caching

asked Jun 1, 2021 at 10:39

Marcello Impastato's user avatar

5

  • Maybe this page can help

    Jun 1, 2021 at 10:51

  • Try Cache-Control: public, max-age=31536000, immutable in 2nd block.

    Jun 2, 2021 at 7:50

  • @anubhava nothing. i have tried to put it in format for htaccess but not work (err 500) and tried in three lines separated and i continue to display that error.

    Jun 2, 2021 at 14:08

  • Is that your full .htaccess?

    Jun 2, 2021 at 16:18

  • only it for test.

    Jun 3, 2021 at 9:10

Load 7 more related questions

Show fewer related questions

Web programming: ‘cache-control header is missing or empty’

Self-tutoring about web experimentation: the tutor shares an observation.

In Developer Tools, I get the ‘cache-control header is missing or empty’ when I load a local file, but not one from a server. I’m under the impression that, when that header is absent, the browser reloads stylesheets, images, etc, each time, while it typically would cache them when the header is set. It’s actually useful to have it not, therefore, when experimenting with a stylesheet.

Source:

stackoverflow.com

Jack of Oracle Tutoring by Jack and Diane, Campbell River, BC.

This article is a part of our Web Security Knowledge Base
(back to index)

Why Incomplete or No Cache-control and Pragma HTTP Header Set can be dangerous

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser or proxy cache.

The ‘Cache-control’ HTTP header holds instructions for caching in both requests and responses. The ‘Pragma’ header is used for backwards compatibility with HTTP/1.0 where the ‘Cache-control’ header is not yet presented.

Make sure the ‘Cache-control’ HTTP header is set with ‘no-cache, no-store, must-revalidate’ and the ‘Pragma’ header is set to ‘no-cache’ on HTTP response where possible.

Example:

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache

How does ScanRepeat report Incomplete or No Cache-control and Pragma HTTP Header Set

ScanRepeat analyzes every HTTP response checking whether it should contain HTTP ‘Cache-control’ header and reports every occurrence of it missing or being incomplete. The ‘Pragma’ header is reported incomplete when it is present in the HTTP response and it’s value differs from ‘no-cache’.
ScanRepeat report includes HTTP requests URLs of every discovered misconfiguration of ‘Cache-control’ and ‘Pragma’ headers along with their incorrect values.

Would you like to test your application now against this problem? Sign up for our
free trial

Scan Your Web App Now

Возможно, вам также будет интересно:

  • 9с59 ошибка обновления windows 7 как исправить
  • 9с59 ошибка обновления windows 7 internet explorer 11
  • 9с57 ошибка обновления windows 7 internet explorer 11
  • 9с55 ошибка бмв е70
  • 9cbc ошибка bmw e60

  • Понравилась статья? Поделить с друзьями:
    0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии