Заголовок last-modified ускоряет индексацию новых страниц в разы

Введение

В старые добрые времена, когда создание web-сайтов представляло из себя
такое простое занятие, как набор нескольких HTML-страниц,
отправка web-страниц в браузер была простой отправкой файла web-сервером.
Посетители сайта могли видеть эти небольшие, исключительно текстовые
странички, почти мгновенно (если не считать пользователей медленных
модемов). Как только страница была загружена, браузер кэширует её
где-нибудь на локальном компьютере, чтобы в случае повторного запроса
страницы, можно было взять его локальную версию из кэша, послав лишь
короткий запрос, чтобы убедиться, что страница на сервере не была
изменена. Запросы обрабатывались быстро и как можно эффективней, и все
были счастливы (кроме использующих модемы 9600 бод).

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

1. Когда сервером получен запрос динамической web-странички,
   производится некоторая промежуточная обработка, например синтаксический
   анализ (парсинг) скрипта движком PHP, которая должна быть
   завершена. Благодаря этому получаем задержку перед тем, как web-сервер
   начнёт отправку вывода в браузер. Для простого PHP-скрипта это
   не существенно, но для более сложного приложения движок PHP
   может выполнить много действий прежде чем страница будет готова для
   отправки. Эти дополнительные действия приводят к заметной задержке между
   запросами пользователей и реальным отображением страниц в их браузерах.
2. Типичный web-сервер, например Apache, использует время модификации
   файла чтобы правильно сообщить web-браузеру состояние кэша запрашиваемой
   странички. Для динамических web-страниц, фактически PHP-скрипт
   может изменяться только изредка, в то время как отображаемый им контент,
   возможно располагающийся в базе данных, изменяется часто. Web-сервер не
   имеет возможности знать о наличии изменений в базе данных, тем не менее
   он не отправляет дату последней модификации. Если клиент (браузер) не
   получает никакого признака того, как долго данные являются корректными,
   он предполагает, что в следующий раз необходимо запросить страничку по
   новой. Web-сервер всегда будет отвечать обновлённой версией странички,
   независимо от того, изменились ли данные. Чтобы избежать этого
   недостатка большинство web-разработчиков используют мета-тэги или
   HTTP-заголовки, чтобы сообщить браузеру никогда не использовать
   кэшированную версию странички. Однако это отрицает естественную
   способность web-браузера кэшировать web-страницы и обладает некоторыми
   существенными недостатками. Например, содержание динамической странички
   может изменяться раз в сутки, поэтому выгода, получаемая от наличия даже
   24-часового кэширования странички браузером, очевидна.

Обычно для маленьких PHP-приложений вполне можно игнорировать
существование этих проблем, однако с увеличением сложности и повышением
трафика Вашего сайта Вы можете столкнуться с проблемами. Тем не менее, обе
эти проблемы могут быть решены, первая путём кэширования на стороне
сервера, вторая путём управления кэшированием на стороне клиента из вашего
приложения. Подход, который вы будете использовать для решения проблем,
будет зависеть от вашей области применения, но в этой главе мы увидим, как
вы можете решить обе проблемы используя PHP и некоторые классы библиотеки
PEAR.

Как добавить и настроить Last-Modified в WordPress

Чтобы добавить Last-Modified в Вордпресс, существует несколько вариантов. Рассмотрим их ближе.

Установка кеширующего плагина

Я рекомендую попробовать настроить WP Super Cache. После прохождения по вышеуказанной инструкции, заголовки Last-Modified будут прописываться самим сервером.

При настройке NGINX обязательно отключите

Учтите, заголовок Last-Modified, в данном случае, будет показывать не дату последнего изменения записи, а дату создания кешированной копии страницы, которая, в свою очередь, зависит от того, как вы настроили обновление кеша. Что, в принципе, является вполне нормальным: поисковые системы, для определения даты последнего изменения документа, смотрят, в первую очередь, в разметку, а браузеру подойдёт и дата обновления кеша.

Правим headers.php

У вас в директории с темой WordPress (), скорее всего, есть отдельный файл шаблона .
Открываем его и в самой первой строке перед всем кодом записываем

<?php header("Last-Modified: " . get_the_modified_date('r'))?>

Учтите, этот вариант, возможно, не будет работать так, как вы ожидаете, при наличии установленного и настроенного кеширующего плагина.

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

Last-Modified: Mon, 15 Jul 2013 14:03:55 +0000

Если файла шаблона header.php нет, то попробуйте следующий вариант.

Установка плагина Last-Modified

Как и в предыдущем пункте, этот вариант будет работать только при отсутствии кеширующего плагина на сайте, например, WP Super Cache. Однако, я настоятельно рекомендую использовать последний, так как страничный кеш никогда не помешает любому хорошему проекту.

Если не доверяете плагину, можете просто взять код ниже и записать его в functions.php или, что лучше, сделать на его основе MU plugin

<?php
/**
 * Установка HTTP заголовка Last-Modified
 * При активации плагина, у всех незапароленных постов в HTTP-заголовках появится Last-Modified
 * https://sheensay.ru/?p=247
 */

add_action( 'template_redirect', 'Sheensay_HTTP_Headers_Last_Modified' );

function Sheensay_HTTP_Headers_Last_Modified() {

	if ( ( defined( 'DOING_AJAX' ) && DOING_AJAX ) || ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) || ( defined( 'REST_REQUEST' ) && REST_REQUEST ) || ( is_admin() ) ) {
		return;
	}

	$last_modified = '';


	// Для страниц и записей
	if ( is_singular() ) {
		global $post;

		// Если пост запаролен - пропускаем его
		if ( post_password_required( $post ) )
			return;

		if ( !isset( $post -> post_modified_gmt ) ) {
			return;
		}

		$post_time = strtotime( $post -> post_modified_gmt );
		$modified_time = $post_time;

		// Если есть комментарий, обновляем дату
		if ( ( int ) $post -> comment_count > 0 ) {
			$comments = get_comments( array(
				'post_id' => $post -> ID,
				'number' => '1',
				'status' => 'approve',
				'orderby' => 'comment_date_gmt',
					) );
			if ( !empty( $comments ) && isset( $comments ) ) {
				$comment_time = strtotime( $comments -> comment_date_gmt );
				if ( $comment_time > $post_time ) {
					$modified_time = $comment_time;
				}
			}
		}

		$last_modified = str_replace( '+0000', 'GMT', gmdate( 'r', $modified_time ) );
	}


	// Cтраницы архивов: рубрики, метки, даты и тому подобное
	if ( is_archive() || is_home() ) {
		global $posts;

		if ( empty( $posts ) ) {
			return;
		}

		$post = $posts;

		if ( !isset( $post -> post_modified_gmt ) ) {
			return;
		}

		$post_time = strtotime( $post -> post_modified_gmt );
		$modified_time = $post_time;

		$last_modified = str_replace( '+0000', 'GMT', gmdate( 'r', $modified_time ) );
	}


	// Если заголовки уже отправлены - ничего не делаем
	if ( headers_sent() ) {
		return;
	}

	if ( !empty( $last_modified ) ) {
		header( 'Last-Modified: ' . $last_modified );

		if ( !is_user_logged_in() ) {
			if ( isset( $_SERVER ) && strtotime( $_SERVER ) >= $modified_time ) {
				$protocol = (isset( $_SERVER ) ? $_SERVER : 'HTTP/1.1');
				header( $protocol . ' 304 Not Modified' );
			}
		}
	}
}

Теперь должно сработать.

Проверить Last-Modified

Когда передача заголовка клиенту настроена, не повредит проверка last modified на корректность. Проверить Last-Modified на собственном или стороннем сайта можно через .

Или сделать свою проверку на корректную обработку заголовка Last-Modified:

<?php
$ch = curl_init();

 $url = 'http://site.ru/1.php ';

 curl_setopt($ch, CURLOPT_URL, $url);
 curl_setopt($ch, CURLOPT_HEADER, true);
 curl_setopt($ch, CURLOPT_NOBODY, true);
 curl_setopt($ch, CURLOPT_HTTPHEADER, array(
 'If-Modified-Since: Sun, 01 Sep 2001 17:33:22 GMT'
 ));

 ob_start();
 curl_exec ($ch);
 curl_close ($ch);
 $data = ob_get_contents();
 ob_end_clean();

 echo nl2br($data);
?>

Настройка заголовка Last-Modified и обработка заголовка If-Modified-Since будет крайне полезна любому более или менне крупному сайту. Скорость обработки страниц сайта может стать значительным фактором улучшения ранжирования сайта в поиске. Сравнительно несложная настройка не создаст проблем, тем более, что для популярных CMS вроде joomla, wordpress, modx и т.д. существуют готовые решения.

Безопасность

Помимо уменьшения времени отклика веб-сервера, необходимо позаботиться о безопасности. Разберем основные http заголовки, которые могут представлять угрозу.

X-XSS-Protection

Заголовок может предотвратить некоторые XSS-атаки.

Вы можете реализовать защиту XSS, используя три варианта в зависимости от конкретной потребности.

• Это полностью отключит фильтр
• Это включает фильтр, но очищает только потенциально вредоносные скрипты
• Это включает фильтр и полностью блокирует страницу.

X-Frame-Options

Заголовок позволяет снизить уязвимость вашего сайта для clickjacking-атак. Этот заголовок служит инструкцией для браузера не загружать вашу страницу в frame/iframe. Не все браузеры поддерживают этот вариант.

Настроить X-Frame-Options можно тремя способами:

• : это полностью отключит функции iframe.
• : iframe может использоваться только кем-то из того же источника.
• : Это позволит размещать страницы в окнах iframe только с определенных URL-адресов.

X-Permitted-Cross-Domain-Policies

Аналогично механизму браузеров блокировки стороннего контента Adobe Flash имеет свой. Он регулируется файлами crossdomain.xml сайта, начиная с корневого каталога. Проблема с механизмом в том, что на любом уровне вложенности корневой регулирующий файл (политика безопасности) может быть переопределен. Чтобы избежать таких ситуаций, необходимо задать этот HTTP-заголовок.

Доступно несколько вариантов настройки:

• — никакая политика не допускается
• — разрешить только главную политику
• — все позволено
• — Разрешить только определенный тип контента. Пример — XML
• — применимо только для FTP-сервера

Strict-Transport-Security

Заголовок Strict-Transport-Security запрещает использование незащищенного HTTP соединения на сайте, если есть защищенное HTTPS.

X-Content-Type-Options

Рейтинг наиболее опасных к использованию возможностей браузера возглавляет возможность Internet Explorer «угадывать» тип файла, игнорируя его MIME-тип.

При передаче от сервера к браузеру все файлы имеют тот или иной тип, который прямо указывает на суть содержимого файла. Однако, Internet Explorer имеет встроенный механизм, который позволяет по-содержимому файла переопределить его тип.

Таким образом, обычные текстовые файлы могут быть интерпретированы как JavaScript со всеми вытекающими последствиями. Например, если у вас на сайте запрещена загрузка текстовых файлов с расширениями .js пользователями, то они могут загрузить в виде картинок текстовый файл, содержащий JavaScript-код, который может быть исполнен браузером.

Заголовки HTTP, используемые по промежуточного слоя кэширования ответов

В следующей таблице приведены сведения о заголовках HTTP, влияющих на кэширование ответов.

Заголовок	Сведения
	Ответ не кэшируется, если заголовок существует.
	По промежуточного слоя рассматривает только ответы кэширования, отмеченные директивой Cache. Управление кэшированием со следующими параметрами: максимальный возраст максимальный — устаревший† min-свежая must-revalidate no-cache без магазина только в случае кэширования private public s-maxage прокси — повторная проверка‡ †если ограничение не задано , по промежуточного слоя не выполняет никаких действий.‡ имеет тот же результат, что и .Дополнительные сведения см. в разделе .
	Заголовок в запросе дает тот же результат, что и . Этот заголовок переопределяется соответствующими директивами в заголовке, если он имеется. Рассматривается для обеспечения обратной совместимости с HTTP/1.0.
	Ответ не кэшируется, если заголовок существует. Любое по промежуточного слоя в конвейере обработки запросов, которое задает один или несколько объектов, cookie предотвращает кэширование ответа по промежуточного слоя (например, ).
	Заголовок используется для изменения кэшированного ответа другим заголовком. Например, ответы кэшируются по кодировке путем включения заголовка, который кэширует ответы для запросов с заголовками и по отдельности. Ответ со значением заголовка объекта никогда не сохраняется.
	Ответ, который считается устаревшим по этому заголовку, не сохраняется или не извлекается, если он не переопределен другими заголовками.
	Полный ответ обрабатывается из кэша, если значение не равно, а ответ не совпадает ни с одним из указанных значений. В противном случае выдается ответ 304 (не изменено).
	Если заголовок отсутствует, полный ответ передается из кэша, если значение кэшированной даты ответа новее заданного значения. В противном случае обслуживается ответ 304 — не изменено .
	При обслуживании из кэша заголовок задается по промежуточного слоя, если оно не было указано в исходном ответе.
	При обслуживании из кэша заголовок задается по промежуточного слоя, если оно не было указано в исходном ответе.
	Заголовок, отправленный в исходном ответе, игнорируется. По промежуточного слоя выполняет вычисление нового значения при обработке кэшированного ответа.

Оптимизация работы с файлами

позволяет использовать более совершенный системный вызов, который обеспечивает прямую передачу файла, то есть без системных вызовов read + write.

включает использование асинхронного обращения к файлам, что избавит от очередей запросов.

позволит передавать заголовок ответа и начало файла в одном пакете.

по умолчанию выключена. Задает настройку для кэширования информации о файлах, с которыми работает nginx. По умолчанию выключено.

задает время, через которое веб-сервер будет проверять актуальность данных. По умолчанию 60 секунд.

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

Зачем нужны заголовки Last-Modified и If-Modified-Since?

1. Когда сервер отдаёт такой код, то выполнение всех PHP сценариев на странице даже не запускается. Страница загружается из кэша поиска, а это, как Вы понимаете, весьма существенно снижает нагрузку на сервер к вящей радости Вашего хостера и ускоряет загрузку страницы у посетителя, что тоже не может не радовать.

Как это происходит?

Сканируя интернет, пауки Google и Яндекса сохраняют в своей базе копию каждого сайта. Эта копия служит неким образцом для сравнения: все ли по-прежнему или произошли изменения. И если не настроены заголовки Last-Modified и If-Modified-Since или настроены неправильно, новые страницы сайта проходят индексацию, а главная в кэше поисковиков долго не обновляется, как не обновляется и лента комментариев.

2. Далее. В процессе оптимизации мы тем или иным способом включаем кеширование на стороне браузера, и это правильно, т.к. эта процедура тоже сокращает нагрузку на сервер.

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

Если Ваш сайт обновляется часто (например, Ваши записи часто комментируют)  можно отключить кеширование следующим набором заголовков:

Это означает, что действительность сохранённой копии должна перепроверяться при каждом запросе.

Как  работает кэширование в браузерах?

Если оно не запрещено вызовом функции no_cache, то в Firefox и в IE страница сохраняется в кэше, при всех последующих запросах выдается именно она.

Чтобы обновить страницу и получить ее свежую версию, нужно нажать комбинацию клавиш Ctrl + F5, обычная кнопка «Обновить» (F5) не срабатывает. И надо сказать, документы в кэше IE могут храниться очень-очень долго.

В Опере страница кэш очищается по нажатию кнопки «Обновить» или клавиши F5. Сочетание CRTL+F5 в Опере — перезагрузка всех открытых вкладок, Как Вы понимаете, если Вы их много наоткрывали – в процессе ожидания у Вас может отрасти борода.

Если запретить кэширование страницы функцией no_cache, то Опера и Firefox при обращении к такой странице используют механизм с заголовком If-Modified-Since. Таким образом, кэширование происходит, но браузер спрашивает у сервера, изменилась ли страница на самом деле, или нет – это правильная постановка вопроса.

Следовательно, нужно подключить обработку и этого параметра. Я не буду расписывать, что и какая функция означает, просто приведу код, который корректно отдает заголовки и не вызывает конфликтов на большинстве хостингов, с которыми мне приходилось работать. Эта конструкция работает на sweb.ru, eomy.net, timeweb.ru, fastvps.ru, startlogic.com

Таким образом, все, что Вам нужно сделать, это скопировать данный код и добавить его в файл header.php Вашей темы оформления НАД <!DOCTYPE html>. Т.е. этот код – находится в самом верху файла ДО всего остального кода

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

Проверяем результат на сервисе проверки заголовков Last-Modified и If-Modified-Since

• Если результат положительный – утираем пот со лба и идем пить чай.
• Если результат отрицательный, ту же конструкцию можно добавить в файл index.php в корне Вашего WordPress (с этим я столкнулась на хостинге timeweb.ru). Точно так же, выше всего остального в нем. Только не забудьте про это, когда будете обновлять движок – индексный файл перезапишется в стандартном его виде.

Вуаля! Правильно настроив заголовки Last-Modified и If-Modified-Since, мы получили кучу бонусов:

Как используется и работает nginx

NGINX является широко используемым продуктом в мире IT, по популярности уступая лишь Apache.
Как правило, его используют либо как самостоятельный HTTP-сервер, используя в бекенде PHP-FPM, либо в связке с Apache, где NGINX используется во фронтэнде как кеширующий сервер, принимая на себя основную нагрузку, отдавая статику из кеша, обрабатывая и отфильтровывая входящие запросы от клиента и отправляя их дальше к Apache. Apache работает в бекэнде, работая уже с динамической составляющей проекта, собирая страницу для передачи её в кеш NGINX и запрашивающему её клиенту. Это если в общих чертах, чтобы понимать суть работы, так-то внутри всё сложнее.

Цели кеширования

Кеширование в HTTP не является обязательным, однако в большинстве случаев бывает полезно повторно использовать ранее сохранённые ресурсы. Тем не менее, стандартные кеши HTTP обычно способны кешировать только ответы на запросы методом , а другие отклоняют.

Первичный ключ состоит из метода запроса и запрашиваемого URI (зачастую используется только URI, поскольку целью кеширования являются только GET-запросы). Вот примеры того, что обычно записывается в кеш:

• Успешно загруженные ресурсы: ответ  на запрос методом HTML-документов, изображений или файлов.
• Постоянные перенаправления: ответ («перемещено навсегда»).
• Сообщения об ошибках: ответ («не найдено»).
• Неполные результаты: ответ («частичное содержимое»).

• Ответы на запросы отличные от , если есть что-либо, подходящее для использования в качестве ключа кеша.

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

Конфигурация

Используйте Microsoft.AspNetCore.app метапакет или добавьте ссылку на пакет Microsoft. AspNetCore. респонсекачинг .

В добавьте по промежуточного слоя кэширования ответа в коллекцию служб:

Настройте приложение для использования по промежуточного слоя с помощью UseResponseCaching метода расширения, который добавляет по промежуточного слоя в конвейер обработки запросов в :

Пример приложения добавляет заголовки для управления кэшированием последующих запросов:

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

Предыдущие заголовки не записываются в ответ и переопределяются при работе контроллера, действия или Razor страницы:

Имеет атрибут . Это применимо, даже если свойство не задано. Например, пропуск свойства варибихеадер приведет к удалению соответствующего заголовка из ответа.

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

Предупреждение

Ответы, содержащие содержимое для прошедших проверку клиентов, должны быть помечены как недоступные для кэширования, чтобы предотвратить хранение и обслуживание этих ответов по промежуточного слоя. Сведения о том, как по промежуточного слоя определяет, является ли ответ кэшированным, см. в разделе .

Регенерация содержания на лету

Динамически созданные, но статически обслуживаемые страницы,
т.е. страницы которые должны передаваться как чисто статические
(считываемые из файловой системы и затем передаваемые по запросу),
однако они должны быть динамически сгенерированны веб-сервером если они отсутствуют в файловой системе.
Таким образом вы можете иметь страницы сгенерированные PHP которые являются статически обслуживаемыми
если только кто-либо (либо планировщик) не удалит статическое содержание. В таком случае содержание обновляется.

Это делается следующим набором директив:

    RewriteCond %{REQUEST_FILENAME}   !-s
    RewriteRule ^page\.html$          page.php   [T=application/x-httpd-php,L]

Здесь, запрос к page.html приводит к внутреннему запуску соответствующего page.php,
если page.html все-ещё отсутствует или имеет нулевой размер.
Фокус здесь в том что page.php это обычный PHP скрипт который в дополнение к собственному выводу, записывает свой
вывод в файл page.html.
Запустив это один раз, сервер передает данные page.html.
Когда вебмастер хочет обновить содержание, он просто удаляет page.html (обычно с помощью cronjob).

Http заголовки для управления клиентским кэшированием

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

Без кэша (при отсутствии кэширующих http-заголовков)

Как мы видим, каждый раз при отображении картинки cat.png браузер будет снова загружать ее с сервера. Думаю, не нужно объяснять, что это медленно и неэффективно.

Заголовок ответа и заголовок запроса .

Идея заключается в том, что сервер добавляет заголовок к файлу (ответу), который он отдает браузеру.

Теперь браузер знает, что файл был создан (или изменен) 1 декабря 2014. В следующий раз, когда браузеру понадобится тот же файл, он отправит запрос с заголовком .

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

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

Заголовок ответа и заголовок запроса .

Принцип работы очень схож с , но, в отличии от него, не привязан ко времени. Время – вещь относительная.

Идея заключается в том, что при создании и каждом изменении сервер помечает файл особой меткой, называемой , а также добавляет заголовок к файлу (ответу), который он отдает браузеру:

Теперь браузер знает, что файл актуальной версии имеет равный “686897696a7c876b7e”. В следующий раз, когда брузеру понадобится тот же файл, он отправит запрос с заголовком .

Сервер может сравнить метки и, в случае, если файл не изменялся, отправить браузеру пустой ответ со статусом . Как и в случае с браузер выяснит, что файл не обновлялся и сможет отобразить копию из кэша.

Заголовок

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

В следующий раз браузер, зная, что “дата истечения срока годности” еще не наступила, даже не будет пытаться делать запрос к серверу и отобразит файл из кэша.

Такой вид кэша особенно актуален для иллюстраций к статьям, иконкам, фавиконкам, некоторых css и js файлов и тп.

Заголовок с директивой .

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

Для справки:

• 1 день = 86400 секунд
• 1 неделя = 604800 секунд
• 1 месяц = 2629000 секунд
• 1 год = 31536000 секунд

К примеру:

У заголовка , кроме , есть и другие директивы. Давайте коротко рассмотрим наиболее популярные:

public
Дело в том, что кэшировать запросы может не только конечный клиент пользователя (браузер), но и различные промежуточные прокси, CDN-сети и тп. Так вот, директива позволяет абсолютно любым прокси-серверам осуществлять кэширование наравне с браузером.

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

no-cache
Позволяет указать, что клиент должен делать запрос на сервер каждый раз. Иногда используется с заголовком , описанным выше.

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

must-revalidate
Эта директива предписывает браузеру делать обязательный запрос на сервер для ре-валидации контента (например, если вы используете eTag). Дело в том, что http в определенной конфигурации позволяет кэшу хранить контент, который уже устарел. обязывает браузер при любых условиях делать проверку свежести контента путем запроса к серверу.

proxy-revalidate
Это то же, что и , но касается только кэширующих прокси серверов.

s-maxage
Практически не отличается от , за исключением того, что эта директива учитывается только кэшем резличных прокси, но не самим браузером пользователя. Буква “s-” исходит из слова “shared” (например, CDN). Эта директива предназначена специально для CDN-ов и других посреднических кэшей. Ее указание отменяет значения директивы и заголовка . Впрочем, если вы не строите CDN-сети, то вам вряд ли когда-либо понадобится.

Как перезагрузить nginx

Для перезагрузки NGINX используйте или .
Команда в консоли:

service nginx reload

либо

/etc/init.d/nginx reload

либо

nginx -s reload

Эти команды остановят и перезапустят сервер NGINX.

Перезагрузить конфигурационный файл без перезагрузки NGINX можно так:

nginx -s reload

Проверить правильность конфигурации можно командой

nginx -t 

В чём разница между reload и restart

Как происходит перезагрузка в NGINX:

1. Команда посылается серверу
2. Сервер анализирует конфигурационный файл
3. Если конфигурация не содержит ошибок, новые процессы открываются с новой конфигурацией сервера, а старые плавно прекращают свою работу
4. Если конфигурация содержит ошибки, то при использовании
   1. процесс перезагрузки сервера прерывается, сервер не запускается
   2. сервер откатывается назад к старой конфигурации, работа продолжается

Короче говоря, обрывает работу резко, делает это плавно. рекомендуется использовать, только когда внесены глобальные изменения, например, заменено ядро сервера, либо нужно увидеть результат внесённых изменений прямо здесь и сейчас. В остальных случаях используйте reload.

Ещё лучше, если вы будете предварительно проверять правильность конфигурации командой , например:

nginx -t && service nginx reload

или

nginx -t && nginx -s reload