Заголовок Pragma дает возможность отправлять директивы, которые могут относиться к любому получателю на пути от клиента к исходному серверу, т.е. директивы для прокси-серверов и шлюзов. Директива - это способ указать для программных компонентов определенный вариант обработки запроса или ответа. Слово "pragma" означает "указание транслятору".

Заголовок Pragma, введенный в HTTP/1.0 может содержать только одну директиву:

HTTP
Pragma: no-cache

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

Если единственная директива no-cache относится только к заголовку запроса, почему тогда спецификация RFC 1945 относит этот заголовок к общим заголовкам? В HTTP/1.0 этот заголовок задумывался как поле, которое будет хранить в себе любые директивы для прокси-серверов, как в запросах, так и в ответах.

Но в последствии от этой идеи отказались, т.к. директив для прокси-серверов стало так много, что благоразумнее было сгруппировать их в разных заголовках. В протоколе HTTP/1.1 этот заголовок был оставлен по соображениям совместимости и видимо чисто по историческим причинам его продолжают считать общим заголовком. Однако в документе RFC 2616 особо отмечено, что никаких новых директив для этого заголовка вводиться не будет.

Распространенные ошибки

Заголовок Pragma: no-cache нет никакого смысла включать в заголовки ответа. Любые обсуждения PHP-программистов и других разработчиков серверных приложений относительно этого заголовка основаны на незнании протокола HTTP. Сложно сказать, что подразумевают разработчики, когда включают в ответ заголовок Pragma: no-cache. То ли они хотят дать указание браузеру клиента не кэшировать этот ответ, то ли хотят заставить прокси-серверы не кешировать этот ответ. Первое предположение неверно в корне, т.к. само название заголовка Pragma говорит о том, что это директивы для прокси-серверов. Второе предположение более логично, но тоже ошибочно. Заголовок Pragma: no-cache не заставит прокси-сервер отказаться от кэширования данного сообщения.
Тот факт, что на странице мануалов на php.net по обсуждению PHP-функции header() в примерах постоянно фигурирует этот заголовок, данная ошибка кочует от одного копипастера к другому. Некоторые даже осмеливаются давать советы и писать заметки.

Существует так же другое заблуждение, брошенное с легкой руки авторами статей на тему кэширования. На просторах рунета можно встретить статьи утверждающие, что заголовок Pragma: no-cache - устаревший и все браузеры и прокси его игнорируют. Браузеры то его точно игнорируют, т.к. он для них не предназначен, а вот прокси-серверы не должны его игнорировать, если претендуют на полную совместимость с протоколами HTTP/1.0 и HTTP/1.1
В документе RFC 2616 сказано, что если заголовок Pragma: no-cache присутствует в запросе, прокси-сервер ДОЛЖЕН (уровень SHOULD) отправить запрос дальше к серверу-источнику, даже если у него есть кэшированная копия запрашиваемого ресурса.

Другие ошибки, перекочевавшие из тех же мануалов на php.net, связаны с тем, что заголовок Pragma путают с заголовком Cache-Control. Например директиву public, присущую только заголовку Cache-Control, вписывают в заголовок Pragma.

Курьезы

Опять страница мануалов на php.net по обсуждению PHP-функции header() дарит нам очередное заблуждение, граничащее с бредом. Хотя может быть я слишком груб, и это просто чья-то шутка: Pragma: hack

Чуть ниже этот заголовок кто-то снабдил комментарием "WTF? oh well, it works…". Аббревиатура WTF, означающая "What the fuck", мягко выражаясь, переводится как "Что за хрень!". Этот комментарий в переводе означает "Что это за хрень! Неужели это работает…". Каким образом это должно работать, остается только гадать.

Другая ошибка связана с банальными домыслами. Только школьник может наивно полагать, что если существует директива no-cache, то должна существовать и директива cache. Этот домысел проистекает из другого заблуждения, о котором мы уже говорили: будто директива no-cache заставит браузер не кешировать ответ. Видимо директива cache, по чьему-то глупому разумению, должна заставить браузер кэшировать ответ.

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

Читайте также:

  1. заголовки общие: Cache-Control :: кэш

Комментарии:

  1. Владимир

     

    Столько лет программирую на PHP, не особо разбирался с заголовками, пока не решил все сделать по правилам, и оказывается, что единицы правильно все делают. Просто тупо копипастят. Хорошо, что я нашел этот сайт. Лучше позно чем никогда. А всего-то захотел на сайте сделать толковое кеширование, с обработкой last modified и etag. Благо это предлагает фреймворк Slim из коробки. Но сталкнулся с тем, что не все так легко. Оказывается, что локально все работает замечательно, а у хостера все запросы жестко кешируются на месяц и все! Даже редиректы кешируются намертво. К моим заголовкам добавляется Expires: +1 month, даже когда я указываю, expires: +1 day.

    • Автор

       

      Но тут вам ничего не сделать, если заголовки добавляются после PHP интерпретатора. Либо разбирайтесь с хостером (может быть он позволяет как-то менять эти настройки), либо меняйте его на другого.

  2. Oleg

     

    На моём хостинге, при обращениям к сценариям PHP, сервер всегда включает в ответ заголовок Pargma: no-cache. Причём в скриптах этот заголовок нигде не устанавливается - толи его добавляет сам Apache, толи интерпретатор PHP. Возможно, это какие-то настройки, о которых я не знаю. Могу ли я как-то исключить этот заголовок из ответов сервера? Например, средствами PHP или, возможно, через .htaccess?

    • Автор

       

      Я никогда не сталкивался с задачей удаления заголовка. Скорее всего он добавляется уже после PHP. Я думаю самое правильное - обратится с этим вопросом в службу технической поддержки вашего хостера.

  3. Nuclear_X

     

    Спасибо за статью. Осваиваю PHP помаленьку. Информация пригодится, думаю.

  4. Артем

     

    Спасибо за статью. У вас, в отличии от большинства других ресурсов, материал написан со знанием дела.

  5. Мария

     

    Спасибо, очень полезная и интересная статья.