Не кэшировать


Содержание

Запретить браузеру кэшировать стили и js-скрипты

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

07.02.2020, 16:33

Запретить браузеру переносить строку
Все доброго времени суток. Нужно написать два слова в рамке, в одну строку. Одно слово слева.

Как правильно подключить JS-скрипты и CSS-стили к HTML странице
Доброго времени суток уважаемые! Я к Вам попал из соседней ветки (Delphi). Сразу скажу, с HTML.

Как запретить все стили второй таблице?
Есть таблица, для неё в css файле прописаны th, tr, td. При создании второй таблицы к ней.

Запретить браузеру кешировать страницы
Здравствуйте! Собственно, сабж в заголовке: можно ли запретить браузеру кешировать любые данные из.

Запретить браузеру скачивать файлы
Здравствуйте! Есть задача каким — то образом запретить скачивать файлы из браузера? у меня только.

HTTP-кеширование

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

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

К счастью, HTTP предлагает мощное решение: кэширование . В этом посте объясняется, как HTTP может дать указание браузерам повторно использовать дорогие ресурсы, экономя пропускную способность и время. Мы начнем с обзора концепций кэширования, а затем опишем, как эволюционировал механизм кэширования HTTP между HTTP / 1.0 и HTTP / 1.1.

Основы кэширования

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

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

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

Как это сделать? HTTP предлагает два основных средства, первое из которых мы сейчас рассмотрим.

Expires и истоки кеширования HTTP

Expires был введен в HTTP / 1.0 , и, вместе с Pragma , Last-Modified и If-Modified-Since , первую систему кэширования , состоящей протокола HTTP. Это самый простой из имеющихся в вашем распоряжении заголовков кэширования HTTP, указывающий дату, когда данный ресурс устареет:

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

Повторная проверка с Last-Modified и If-Modified-Since

Помните, как мы упоминали, что идеальный кеш будет загружать новый ресурс только тогда, когда он будет уверен на 100%? Один из способов добиться этого — позволить браузерам опрашивать серверы в зависимости от того, действительно ли такой ресурс доступен. Но как браузер может указать, какая версия ресурса у него в настоящее время?

Введите If-Modified-Since. Расширяя наш пример выше, представьте, что браузер хотел получить image.jpeg 15 апреля, на следующий день после даты, указанной в Expires заголовке. Вы заметите, что приведенный выше фрагмент кода содержит Last-Modified заголовок, который указывает, когда сервер в последний раз полагал, что изображение было обновлено.

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

Если изображение изменилось, сервер просто ответит полным ответом, содержащим новое изображение. В противном случае он может ответить 304 Not Modified :

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

cache-control и эволюция HTTP-кеширования

Ограничения Expires привели к появлению cache-control в HTTP/1.1, что значительно увеличило гибкость, с которой разработчики могли кэшировать ресурсы. Вместо того, чтобы строго полагаться на даты, cache-control принимает ряд директив, пару из которых мы обсудим сейчас, а остальные сворачиваются в дискуссии о повторной проверке, безопасности и многом другом.

Директива max-age

Думайте о max-age директиве как о более простой альтернативе Expires . Если вы хотите указать, что ресурс истекает в течение одного дня, вы можете ответить следующим заголовком cache-control :

Обратите внимание, что max-age относится ко времени запроса, поэтому таймер начинает отсчитывать время, когда ресурс входит в кеш. Вы можете спросить: «Зачем переходить на секунды по датам?»

У Марка Ноттингема есть хорошее объяснение , и он подчеркивает простоту, работы с max-age . Учтите следующее:

Мало того, что может быть трудно сопоставить дату Expires с вашим местным часовым поясом, многие реализации сервера просто испортили формат даты, что привело к путанице. max-age будучи простым целым числом, представляющим секунды с момента генерации ответа, гораздо проще использовать.

Самая длинная продолжительность, которую может поддерживать директива max-age , составляет год, который удовлетворяет большинству вариантов использования. Но если вы сообщаете браузеру, что определенный ресурс никогда не изменится, вы также можете использовать более новую директиву immutable , которая выполняет именно это. Имейте в виду, что его применение не является полностью совместимым в разных браузерах, поэтому стоит добавить ее вместе с ним max-age .

Повторная проверка с Etag и If-None-Match

HTTP / 1.1 также представил новую стратегию переаттестации для дополнения If-Modified-Since , сосредоточенную вокруг того, что называют «тегами сущностей».

Вы можете рассматривать теги сущностей как способ, с помощью которого серверы могут однозначно идентифицировать версию ресурса с помощью буквенно-цифрового идентификатора, указанного в заголовке ответа ETag :

Если клиент хочет сообщить серверу, что у него есть конкретная версия ресурса, он предоставляет заголовок запроса If-None-Match при следующем запросе ресурса:

Если последняя версия ресурса не соответствует тегу сущности «abc», сервер ответит новой версией. В противном случае он ответит 304 Not Modified .

Как вы, наверное, догадались, «abc» — это слишком простой идентификатор, который можно использовать для ресурса. Как бы вы гарантировали, что определенный тег сущности соответствует одной версии ресурса, а не другой?

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

Вы можете указать директиву must-revalidate внутри cache-control чтобы информировать клиентов о том, что они должны использовать механизм проверки, будь то теги сущностей или If-Modified-Since , прежде чем выпускать устаревшую копию ресурса из кэша (в случае, если сервер недоступен).

Обеспечение конфиденциальности кэша с помощью private и public

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

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

Чтобы смягчить это, в HTTP / 1.1 были введены директивы public и private в cache-control , которые, хотя и несовершенны, позволяют указывать такие общие кэши, если вы не хотели, чтобы они хранили копию ресурса.

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

Подавление кэширования с помощью no-cache и no-store

HTTP / 1.1 исправил недостаточность заголовка Pragma в HTTP / 1.0 и предоставил веб-разработчикам средства, с помощью которых можно полностью отключить кэширование.

Первая директива, no-cache заставляет кеш повторно проверять ресурс перед повторным использованием. В отличие от этого must-revalidate , no-cache означает, что браузер значительно обновляется во всех случаях, а не только тогда, когда ресурс устарел.

Вторая директива, no-store это молоток: она сигнализирует, что ресурс ни в коем случае не должен входить в кеш.

Указание специфичных для запроса ограничений кэширования

Что если в качестве клиента вы захотите запросить ресурс, который будет обновлен хотя бы в течение определенного периода времени? Хорошая новость заключается в том, что cache-control это не только инструмент для серверов, задающий ограничения кэширования для клиентов, но и доступный для клиентов, чтобы они могли получить ресурс, который соответствует определенным требованиям к кэшированию.

Директивы max-age , no-cache и no-store все они могут быть использованы в запросах клиента. Их значение имеет тенденцию быть обратным тому, что это означает для клиента; например, указание заголовка max-age в запросе говорит любым промежуточным серверам, что они не могут использовать кэшированные ответы старше, чем продолжительность, указанная в директиве.

В дополнение к указанным выше директивам, в cache-control в вашем распоряжении четыре директивы только для запроса.

min-fresh — позволяет клиентам запрашивать ресурсы, которые будут обновлены, по крайней мере, в течение определенного периода в секундах:


Директива max-stale сообщает любым промежуточным серверам кэша, что клиент готов принять несвежий ответ , который не был несвежим больше , чем определенный период времени в секундах:

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

И, наконец, директива only-if-cached сообщает промежуточным кэшам, что клиент хочет получить только кэшированный ответ, и что в противном случае ему не следует связываться с сервером для получения свежей копии. Если кеш не может удовлетворить запрос, он должен вернуть ответ 504 Gateway Timeout .

Илон Маск рекомендует:  JS без jQuery 10 примеров кода, которыми можно обойтись без jquery

Vary и согласованные с сервером ответы

Наша последняя тема посвящена тому, как браузеры на самом деле идентифицируют ресурсы, и как согласование сервера влияет на ситуацию.

На высоком уровне кэш браузера действительно просто смотрит на URL и метод, хотя практически все кешируемые запросы являются запросами GET, практическая реальность такова, что URL, как правило, достаточно, чтобы браузеры идентифицировали ресурсы.

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

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

Заголовок Accept-Encoding указывает на то, что серверу разрешается возвращать ресурс с gzip версией, если он способен делать это. Если сервер принимает этот заголовок во внимание при решении, какой ответ отправить нам, он перечислит его в заголовке Vary , добавленном к его ответу:

Конечным результатом этого должно быть то, что кеш должен использовать не только значение URL для кеширования ответа, но и что он должен также использовать значение заголовка запроса Accept-Encoding для дальнейшей квалификации ключа кеша. Таким образом, если бы другой запрос был сделан с другим значением для Accept-Encoding заголовка, например deflate , его ответ не заменил бы указанный запрос gzip .

Заключение

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

Настройка сжатия и кэширования через .htaccess

Включить кэширование .htaccess для статических файлов возможно на виртуальном хостинге Linux в Plesk и cPanel. Чтобы управлять настройками кэширования, используйте модуль expires. Как настроить кэширование в ISPmanager?

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

Настройка кэширования:

Настройка expires: 1. Для настройки кэширования сайта .htaccess файл должен находиться в корневой директории вашего сайта. Если у вас нет этого файла воспользуйтесь справкой: У меня нет файла .htaccess, что делать?.

Добавьте в файл .htaccess строки следующего вида:

Настройка сжатия

На серверах виртуального хостинга сжатие .htaccess для статических файлов включено по умолчанию. Статические файлы обрабатываются веб-сервером Nginx, доступа к настройке которого нет.

Проверить наличие сжатия можно при помощи ресурса.

Если вам критична настройка сжатия, рекомендуем приобрести VPS сервер.

Не работает кэширование .htaccess

Если после указанных настроек кэширование .htaccess не работает или у вас возникли сложности, обратитесь в техническую поддержку.

Виртуализация KVM, почасовая оплата, резервные копии, готовые шаблоны, 10 доступных ОС на выбор!

Как отключить кэширование на PHP

У браузеров есть одна очень важная возможность — это кэширование. Данная функция позволяет резко ускорить процесс загрузки страниц. Однако, иногда кэширование приносит большой вред. Например, у Вас на сайте выводятся какие-нибудь котировки валют, которые меняются постоянно. Представьте, что будет, если у пользователей страница будет в кэше, и изменений котировок они не увидят. И вот как отключить кэширование на PHP, я сейчас и напишу.

Для отключения кэширование на PHP достаточно вставить в код скрипта, который вызывается пользователем, следующие строчки:

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

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

  • BB-код ссылки для форумов (например, можете поставить её в подписи):
  • Комментарии ( 2 ):

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

    Для добавления комментариев надо войти в систему.
    Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.

    Copyright © 2010-2020 Русаков Михаил Юрьевич. Все права защищены.

    Обход кэширования js/css

    Всем привет! Хочу задать совсем простой вопрос:

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

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

    • Вопрос задан более трёх лет назад
    • 33687 просмотров

    Наиболее простой для Вас вариант, как мне кажется — это, конечно же, использовать GET-параметр после скрипта:

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

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


    Как бороться с кешированием браузеров

    В web-разработке более логичным и правильным считается вынесение javascript-логики и CSS-стилей в отдельные файлы. Кроме более логичной структуры такая организация файлов снижает нагрузку на сервер и уменьшает траффик. То-есть мы снижаем количество http-запросов и .js и .css файлы отдаются с заголовками, обеспечивающими надежное кеширование этих файлов браузерами. Но когда в процессе развития сайта приходится менять эти файлы, у пользователей в кеше остается старый вариант и пока кеш не устарел, будут поступать жалобы на сломанную интеграцию серверной и клиентской частей.

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

    Простое кеширование ETag

    Самый простой способ кеширования статических ресурсов — использование ETag.

    Достаточно включить соответствующую настройку сервера (для Apache включена по умолчанию) — и к каждому файлу в заголовках будет даваться ETag — хеш, который зависит от времени обновления, размера файла и (на inode-based файловых системах) inode.

    Браузер кеширует такой файл и при последующих запросах указывет заголовок If-None-Match с ETag кешированного документа. Получив такой заголовок, сервер может ответить кодом 304 — и тогда документ будет взят из кеша.

    Выглядит это так:
    1) Первый запрос к серверу (кеш чистый)

    GET /misc/pack.js HTTP/1.1 Host: lifeinweb.biz

    Вообще, браузер обычно добавляет еще пачку заголовоков типа User-Agent, Accept и т.п. Для краткости они порезаны.

    2) Ответ сервера (Сервер посылает в ответ документ c кодом 200 и ETag):

    HTTP/1.x 200 OK Content-Encoding: gzip Content-Type: text/javascript; charset=utf-8 Etag: «3272221997» Accept-Ranges: bytes Content-Length: 23321 Date: Fri, 02 May 2008 17:22:46 GMT Server: lighttpd

    3) Следующий запрос браузера (При следующем запросе браузер добавляет If-None-Match: (кешированный ETag)):

    GET /misc/pack.js HTTP/1.1 Host: umi.lifeinweb.biz If-None-Match: «453700005»

    4) Ответ сервера (Сервер смотрит — ага, документ не изменился. Значит можно выдать код 304 и не посылать документ заново):

    HTTP/1.x 304 Not Modified Content-Encoding: gzip Etag: «453700005» Content-Type: text/javascript; charset=utf-8 Accept-Ranges: bytes Date: Tue, 15 Apr 2008 10:17:11 GMT

    Альтернативный вариант — если документ изменился, тогда сервер просто посылает 200 с новым ETag.

    Аналогичным образом работает связка Last-Modified + If-Modified-Since:

    1) сервер посылает дату последней модификации в заголовке Last-Modified (вместо ETag)
    2) браузер кеширует документ, и при следующем запросе того же документа посылает дату закешированной версии в заголовке If-Modified-Since(вместо If-None-Match)
    3) сервер сверяет даты, и если документ не изменился — высылает только код 304, без содержимого.

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

    Умное кеширование — Версионность

    Общий подход для версионности:

    1) К каждому файлу скрипта или стиля добавляется версия (или дата модификации). Например, //www.webmancer.org/bizmy.js превратится в //www.webmancer.org/bizmy.v1.2.js
    2) Все скрипты жестко кешируются браузером
    3) При обновлении скрипта версия меняется на новую: //www.webmancer.org/bizmy.v2.0.js
    4) Адрес изменился, поэтому браузер запросит и закеширует файл заново
    5) Старая версия 1.2 постепенно выпадет из кеша

    Дальше мы разберем, как сделать этот процесс автоматическим и прозрачным.

    Жесткое кеширование

    Жесткое кеширование — своего рода кувалда которая полностью прибивает запросы к серверу для кешированных документов.

    Для этого достаточно добавить заголовки Expires и Cache-Control: max-age.

    Например, чтобы закешировать на 365 дней в PHP:

    header(«Expires: «.gmdate(«D, d M Y H:i:s», time()+86400*365).» GMT»); header(«Cache-Control: max-age=»+86400*365);

    Или можно закешировать контент надолго, используя mod_header в Apache:

    Header add «Expires» «Mon, 28 Jul 2014 23:30:00 GMT» Header add «Cache-Control» «max-age=315360000»

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

    Большинство браузеров (Opera, Internet Explorer 6+, Safari) НЕ кешируют документы, если в адресе есть вопросительный знак, т.к считают их динамическими.Именно поэтому мы добавляем версию в имя файла. Конечно, с такими адресами приходится использовать решение типа mod_rewrite, мы это рассмотрим дальше в статье.

    P.S: А вот Firefox кеширует адреса с вопросительными знаками..

    Автоматическое преобразование имен

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

    Имя с версией -> Файл

    Самое простое — это превратить имя с версией в оригинальное имя файла.

    На уровне Apache это можно сделать mod_rewrite:

    RewriteEngine on RewriteRule ^/(.*\.)v[0-9.]+\.(css|js|gif|png|jpg)$ /$1$2 [L]

    Такое правило обрабатывает все css/js/gif/png/jpg-файлы, вырезая из имени версию.

    /images/logo.v2.gif -> /images/logo.gif /css/style.v1.27.css -> /css/style.css /javascript/script.v6.js -> /javascript/script.js

    Но кроме вырезания версии — надо еще добавлять заголовки жесткого кеширования к файлам. Для этого используются директивы mod_header:

    Header add «Expires» «Mon, 28 Jul 2014 23:30:00 GMT» Header add «Cache-Control» «max-age=315360000»

    А все вместе реализует вот такой апачевый конфиг:

    RewriteEngine on # убирает версию, и заодно ставит переменную что файл версионный RewriteRule ^/(.*\.)v[0-9.]+\.(css|js|gif|png|jpg)$ /$1$2 [L,E=VERSIONED_FILE:1]# жестко кешируем версионные файлы Header add «Expires» «Mon, 28 Jul 2014 23:30:00 GMT» env=VERSIONED_FILE Header add «Cache-Control» «max-age=315360000» env=VERSIONED_FILE

    Из-за порядка работы модуля mod_rewrite, RewriteRule нужно поставить в основной конфигурационный файл httpd.conf или в подключаемые к нему(include) файлы, но ни в коем случае не в .htaccess, иначе команды Header будут запущены первыми, до того, как установлена переменная VERSIONED_FILE. Директивы Header могут быть где угодно, даже в .htaccess — без разницы.

    Автоматическое добавление версии в имя файла на HTML-странице

    Илон Маск рекомендует:  Что такое код mb_decode_mimeheader

    Как ставить версию в имя скрипта — зависит от Вашей шаблонной системы и, вообще, способа добавлять скрипты (стили и т.п.).

    Например, при использовании даты модификации в качестве версии и шаблонизатора Smarty — ссылки можно ставить так:

    Как заставить веб-браузер не кэшировать изображения

    Я пишу и использую очень простой инструмент управления контентом на основе CGI (Perl) для двух сайтов pro-bono. Он предоставляет администратору веб-сайта HTML-формы для событий, где они заполняют поля (дата, место, название, описание, ссылки и т.д.) И сохраняют его. В этой форме я разрешаю администратору загружать изображение, связанное с событием. На странице HTML, отображающей форму, я также показываю предварительный просмотр загруженного изображения (тег HTML img).

    Проблема

    Проблема возникает, когда администратор хочет изменить изображение. Ему просто нужно нажать кнопку «просмотреть», выбрать новую картинку и нажать «ОК». И это прекрасно работает.

    После загрузки изображения мой внутренний CGI обрабатывает загрузку и перезагружает форму.


    Проблема заключается в том, что изображение, показанное , не обновляется. Старое изображение все еще отображается, хотя база данных содержит правильное изображение. Я сузил его до того, что IMAGE IS CACHED в веб-браузере. Если администратор нажимает кнопку RELOAD в Firefox/Explorer/Safari, все становится хорошо обновленным и появляется новое изображение.

    Мое решение — не работает

    Я пытаюсь управлять кешем, написав инструкцию HTTP Expires с датой, очень далекой в ​​прошлом.

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

    Но это тоже не работает.

    Примечания

    При загрузке изображения его имя не сохраняется в базе данных. Он переименовывается как Image.jpg (просто для использования при его использовании). При замене существующего изображения на новое имя также не изменяется. Просто изменяется содержимое файла изображения.

    Веб-сервер предоставляется службой хостинга /ISP. Он использует Apache.

    Вопрос

    Есть ли способ заставить веб-браузер НЕ кэшировать вещи с этой страницы, даже изображения?

    Я жонглирую с возможностью фактически «сохранить имя файла» в базе данных. Таким образом, если изображение будет изменено, src тега IMG также изменится. Однако для этого требуется много изменений на всем сайте, и я не хочу этого делать, если у меня есть лучшее решение. Кроме того, это все равно не будет работать, если новое загруженное изображение имеет одно и то же имя (скажем, изображение немного портировано и повторно загружено).

    Армин Роначер имеет правильную идею. Проблема в том, что случайные строки могут сталкиваться. Я хотел бы использовать:

    Где «1222259157.415» — текущее время на сервере.
    Генерируйте время с помощью Javascript с помощью performance.now() или с помощью Python с помощью time.time()

    Простое исправление: присоедините произвольную строку запроса к изображению:

    Что сообщает HTTP RFC:

    Но это не так хорошо работает:)

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

    Я бы использовал:

    где «20130910043254» — время изменения файла.

    При загрузке изображения его имя не сохраняется в базе данных. Он переименован в Image.jpg(просто для использования при его использовании). При замене существующего изображения на новое имя также не изменяется. Просто изменяется содержимое файла изображения.

    Я думаю, что есть два типа простых решений: 1) те, которые приходят на ум сначала (прямые решения, потому что их легко придумать), 2) те, с которыми вы закончили, подумав над чем-то (потому что они просты в использовании). По-видимому, вы не всегда будете в выигрыше, если захотите подумать. Но, по-моему, другие варианты довольно недооцениваются. Подумайте, почему php так популярен;)

    Вы можете написать прокси script для обслуживания изображений — это немного больше работает. Что-то нравится:

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

    Я НОВЫЙ Coder, но вот что я придумал, чтобы остановить браузер от кеширования и удерживания на моих представлениях в веб-камерах:

    Не уверен, что работает над тем, что браузер, но он работает для некоторых: IE: Работает, когда веб-страница обновляется и когда веб-сайт пересматривается (без обновления). CHROME: Работает только при обновлении веб-страницы (даже после повторного просмотра). SAFARI и iPad: не работает, мне нужно очистить историю и веб-данные.

    Любые идеи на SAFARI/iPad?

    Результат: src= «images/img1.jpg» => src= «images/img1.jpg? A = 0.08749723793963926»

    При загрузке изображения его имя не сохраняется в базе данных. Он переименовывается как Image.jpg(просто для использования при его использовании).

    Измените это, и вы исправили свою проблему. Я использую временные метки, как и предлагаемые выше решения: Image- .jpg

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

    Я проверил все ответы по сети, и лучший из них, казалось, был: (на самом деле это не так)

    Однако, если вы добавите параметр cache = none (который является статическим «ничем» ), это ничего не влияет, браузер все еще загружается из кеша.

    Решение этой проблемы:

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

    Однако моя проблема была немного иной: Я загружал на лету сгенерированное изображение диаграммы php и управлял страницей параметрами $_GET. Я хотел, чтобы изображение читалось из кеша, когда параметр URL GET остается неизменным и не кэшируется при изменении параметров GET.

    Чтобы решить эту проблему, мне нужно было хэш $_GET, но поскольку это массив, это решение:

    Edit

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

    filemtime() получает время изменения файла.

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

    У меня была очень похожая ситуация с загрузкой изображений продуктов в бэкэнде администратора для хранилища, подобного сайту, и в моем случае я решил, что лучшим вариантом было использование javascript для принудительного обновления изображения без использования какого-либо URL-модификации техники, которые уже упоминались здесь. Вместо этого я помещал URL-адрес изображения в скрытый IFRAME, называемый location.reload(true) в окне IFRAME, а затем заменял свое изображение на странице. Это заставляет обновлять изображение не только на странице, на которой я работаю, но и на любых последующих страницах, которые я посещаю, — ни клиент, ни сервер не должны помнить какие-либо URL-запросы или параметры идентификатора фрагмента.

    Я отправил код, чтобы сделать это в своем ответе здесь.

    Добавьте метку времени «>

    всегда будет давать вашему файлу случайное число в конце и останавливать его кеширование

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

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

    Я предполагаю, что исходный вопрос касается изображений, сохраненных с некоторой текстовой информацией. Таким образом, если у вас есть доступ к текстовому контексту при генерации src=. url, рассмотрите использование/использование CRC32 байтов изображения вместо бессмысленной случайной или временной отметки. Затем, если страница с большим количеством изображений отображается, обновляются только обновленные изображения. В конце концов, если сохранение CRC невозможно, оно может быть вычислено и добавлено к URL-адресу во время выполнения.

    С моей точки зрения, отключить кеширование изображений — плохая идея. Вообще.

    Коренная проблема здесь — как заставить браузер обновлять изображение, когда он был обновлен на стороне сервера.

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

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

    Единственное исключение — это значки. По некоторым причинам это не работает. Я не мог заставить браузер обновлять кеш с сервера. ETags, Cache Control, Expires, заголовки Pragma, ничего не помогли.

    В этом случае добавление некоторого параметра random/version в url, кажется, является единственным решением.

    В идеале, вы должны добавить кнопку/связывание клавиш/меню на каждую веб-страницу с возможностью синхронизации содержимого.

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


    Наивный пример выглядит так:

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

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

    Настройка кэширования через файл .htaccess

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

    Ускорить загрузку Вашего сайта можно с помощью кэширования. Для решения этой задачи Вы можете воспользоваться модулем headers веб-сервера Apache. Он позволяет контролировать и изменять заголовки HTTP-запросов и HTTP-ответов. Вся суть в этом случае сводится к тому, что бы заставить браузер загрузить редко-изменяемые данные с сервера в локальный кэш всего один раз, а далее, при заходе на сайт, использовать данные из кэша. Можно установить кэширование для определенных типов файлов на строго определенное время, по истечению которого файлы будут загружены с сервера вновь. Делается это достаточно просто:

    Для файлов с указанными расширениями в конструкции FilesMatch устанавливается отдаваемый сервером заголовок Cache-Control и переменная max-age , в которой указывается время сохранения файлов в кеше в секундах. Добавьте или удалите расширения файлов, которые для Вас будут уместны в данном случае.

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

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

    Еще одни способ управлять кэшированием — это воспользоваться модулем expires. Этот модуль контролирует установку HTTP-заголовков для кэширования данных на стороне браузера. Продолжительность хранения данных в кэше может быть установлена по времени, по последнему изменению файла или по времени доступа клиента.

    Ниже представлен простой пример использования модуля expires в файле .htaccess:

    В этом примере мы включаем модуль, устанавливаем кэширование по умолчанию на 1 месяц, а далее назначаем для файлов с расширением gif и jpg врема хранения в кэше plus 2 months . Время можно указать в годах, месяцах, неделях, днях, часах, минутах, секундах. В том числе можно использовать вариант вида:

    Илон Маск рекомендует:  Что такое код asp cookies

    В качестве типов файлов можно указывать различные MIME types , вот некоторые из них в качестве примера:

    Лучшие практики кэширования

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

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

    Паттерн №1: неизменяемый контент и долгий max-age кэша

    • Содержимое по URL не меняется, следовательно…
    • Браузер или CDN могут без проблем закэшировать ресурс на год
    • Закэшированный контент, который младше, чем заданный max-age может использоваться без консультации с сервером

    Страница : Эй, мне нужны «/script-v1.js» , «/styles-v1.css» и «/cats-v1.jpg» 10:24

    Кэш : У меня пусто, как насчет тебя, Сервер? 10:24

    Сервер : ОК, вот они. Кстати, Кэш, их стоит использовать в течение года, не больше. 10:25

    Страница : Ура! 10:25

    Страница : Эй, мне нужны «/script-v2.js» , «/styles-v2.css» и «/cats-v1.jpg» 08:14

    Кэш : Картинка с котиками есть, остального нет. Сервер? 08:14

    Сервер : Легко — вот новые CSS & JS. Еще раз, Кэш: их срок годности не больше года. 08:15

    Кэш : Супер! 08:15

    Страница : Спасибо! 08:15

    Кэш : Хм, я не пользовался «/script-v1.js» & «/styles-v1.css» достаточно долго. Пора их удалять. 12:32

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

    В каждом URL есть что-то, меняющееся одновременно с контентом. Это может быть номер версии, модифицированная дата или хэш контента (этот вариант я и выбрал для своего блога).

    В большинстве серверных фреймворков есть инструменты, позволяющие с легкостью делать подобные вещи (в Django я использую Manifest​Static​Files​Storage); есть также совсем небольшие библиотеки в Node.js, решающие те же задачи, например, gulp-rev.

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

    Паттерн №2: изменяемый контент, всегда проходящий ревалидацию на сервере

    • Содержимое URL изменится, значит…
    • Любая локальная закэшированная версия не может использоваться без указания сервера.

    Страница : Эй, мне нужно содержимое «/about/» и «/sw.js» 11:32

    Кэш : Ничем не могу помочь. Сервер? 11:32

    Сервер : Есть такие. Кэш, держи их при себе, но перед использованием спрашивай у меня. 11:33

    Кэш : Так точно! 11:33

    Страница : Спс! 11:33

    На следующий день

    Страница : Эй, мне опять нужно содержимое «/about/» и «/sw.js» 09:46

    Кэш : Минутку. Сервер, с моими копиями все в порядке? Копия «/about/» лежит с понедельника, а «/sw.js» вчерашняя. 09:46

    Сервер : «/sw.js» не менялась… 09:47

    Кэш : Круто. Страница, держи «/sw.js» . 09:47

    Сервер : …но «/about/» у меня новой версии. Кэш, держи ее, но как и в прошлый раз, не забудь сначала спросить меня. 09:47

    Кэш : Понял! 09:47

    Страница : Отлично! 09:47

    Примечание: no-cache не значит “не кэшировать”, это значит “проверять” (или ревалидировать) закэшированный ресурс у сервера. А не кэшировать совсем браузеру приказывает no-store . Также и must-revalidate означает не обязательную ревалидацию, а то, что закэшированный ресурс используется только, если он младше, чем заданный max-age , и только в ином случае он ревалидируется. Вот так все запущено с ключевыми словами для кэширования.


    В этом паттерне мы можете добавить к ответу ETag (идентификатор версии на ваш выбор) или заголовок Last-Modified . При следующем запросе содержимого со стороны клиента, выводится If-None-Match или If-Modified-Since соответственно, позволяя серверу сказать “Используй то, что у тебя есть, твой кэш актуален”, то есть вернуть HTTP 304.

    Если отправка ETag / Last-Modified невозможна, сервер всегда отсылает содержимое полностью.

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

    Это не редкость, когда у нас нет инфраструктуры для первого паттерна, но точно также могут возникнуть проблемы с сетевыми запросами в паттерне 2. В итоге используется промежуточный вариант: короткий max-age и изменяемый контент. Это плохой компромисс.

    Использование max-age с изменяемым контентом это, как правило, неправильный выбор

    И, к сожалению, он распространен, в качестве примера можно привести Github pages.

    С серверным заголовком:

    • Содержимое URL меняется
    • Если в браузере есть кэшированная версия свежее 10 минут, она используется без консультации с сервером
    • Если такого кэша нет, используется запрос к сети, по возможности с If- Modified-Since или If-None-Match

    Страница : Эй, мне нужны «/article/» , «/script.js» и «/styles.css» 10:21

    Кэш : У меня ничего нет, как у тебя, Сервер? 10:21

    Сервер : Без проблем, вот они. Но запомни, Кэш: их можно использовать в течение ближайших 10 минут. 10:22

    Страница : Спс! 10:22

    6 minutes later

    Страница : Эй, мне опять нужны «/article/» , «/script.js» и «/styles.css» 10:28

    Кэш : Упс, я извиняюсь, но я потерял «/styles.css» , но все остальное у меня есть, держи. Сервер, можешь подогнать мне «/styles.css» ? 10:28

    Сервер : Легко, он уже изменился с тех пор, как ты в прошлый раз забирал его. Ближайшие 10 минут можешь смело его использовать. 10:29

    Кэш : Без проблем. 10:29

    Страница : Спасибо! Но, кажется, что-то пошло не так! Все поломалось! Что, вообще, происходит? 10:29

    Этот паттерн имеет право на жизнь при тестировании, но ломает все в реальном проекте и его очень сложно отслеживать. В примере выше, сервер обновил HTML, CSS и JS, но выведена страница со старыми HTML и JS из кэша, к которым добавлен обновленный CSS с сервера. Несовпадение версий все портит.

    Часто при внесении значительных изменений в HTML, мы меняем и CSS, для правильного отражения новой структуры, и JavaScript, чтобы и он не отставал от контента и стилей. Все эти ресурсы независимы, но заголовки кэширования не могут выразить это. В итоге у пользователей может оказаться последняя версия одного/двух ресурсов и старая версия остальных.

    max-age задается относительно времени ответа, поэтому если все ресурсы передаются как часть одного адреса, их срок истечет одновременно, но и здесь сохраняется небольшой шанс рассинхронизации. Если у вас есть страницы, не включающие JavaScript или включающие другие стили, сроки годности их кэша будут рассинхронизированы. И хуже того, браузер постоянно вытаскивает содержимое из кэша, не зная, что HTML, CSS, & JS взаимозависимы, поэтому он с радостью может вытащить что-то одно из списка и забыть про все остальное. Учитывая все эти факторы вместе, вы должны понять, что вероятность появления несовпадающих версий достаточно велика.

    Для пользователя результатом может быть сломанная раскладка страницы или иные проблемы. От небольших глюков до совершенно непригодного контента.

    К счастью, у пользователей есть запасной выход…

    Обновление страницы иногда спасает

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

    Сервис-воркер может продлить жизнь этих багов

    Например, у вас есть такой сервис-воркер:

    • кэширует скрипт и стили
    • использует кэш при совпадении, иначе обращается к сети

    Если мы меняем CSS/JS, мы также увеличиваем номер version , что инициирует обновление. Однако, так как addAll обращается сначала к кэшу, мы можем попасть в состояние гонки из-за max-age и несоответствующих версий CSS & JS.

    После того как они закэшированы, у нас будут несовместимые CSS & JS до следующего обновления сервис-воркера — и это если мы опять не попадем при обновлении в состояние гонки.

    Вы можете пропустить кэширование в сервис-воркере:

    К сожалению, опции для кэширования не поддерживаются в Chrome/Opera и только-только добавлены в ночную сборку Firefox, но вы можете сделать это самостоятельно:

    В этом примере, я сбрасываю кэш с помощью случайного числа, но вы можете пойти дальше и добавлять хэш контента при сборке (это похоже на то, что делает sw-precache). Это своего рода реализация первого паттерна с помощью JavaScript, но работающая только с сервис-воркером, а не браузерами и CDN.

    Сервис-воркеры и HTTP-кэш отлично работают вместе, не заставляйте их воевать!

    Как видите, вы можете обойти ошибки с кэшированием в вашем сервис-воркере, но правильней будет решить корень проблемы. Правильная настройка кэширования не только облегчает работу сервис-воркера, но и помогает браузерам, не поддерживающим сервис-воркеры (Safari, IE/Edge), а также позволяет вам извлечь максимум из вашей CDN.

    Правильные заголовки кэширования также могут значительно упростить обновление сервис-воркера.

    Здесь я закэшировал корневую страницу с паттерном №2 (серверная ревалидация) и все остальные ресурсы с паттерном №1 (неизменяемый контент). Каждое обновление сервис-воркера будет вызывать запрос к корневой странице, а все остальные ресурсы будут загружаться только, если их URL изменился. Это хорошо тем, что сохраняет трафик и улучшает производительность, независимо от того, обновляетесь ли вы с предыдущей или очень старой версии.

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

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

    При аккуратном использовании max-age и изменяемый контент могут быть очень хороши

    max-age очень часто бывает неправильным выбором для изменяемого контента, но не всегда. Например, у оригинала статьи max-age составляет три минуты. Состояние гонки не является проблемой, так как на странице нет зависимостей, использующих одинаковый паттерн кэширования ( CSS, JS & изображения используют паттерн №1 — неизменяемый контент), все остальное этот паттерн не использует.

    Этот паттерн означает, что я спокойно пишу популярную статью, а мой CDN (Cloudflare) может снять нагрузку с сервера, если, конечно, я готов подождать три минуты, пока обновленная статья станет доступной пользователям.

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

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

    Не кэшировать

    Столкнулся с проблемой
    IE не реагирует на тэги (Документ статический html)

    в IE при навигации по сайту кэшируется картинка капчи (по F5 обновляется)
    = «>

    Хотя другие браузеры без проблем понимают.

    Задача 100% НЕ кэшировать либо всю страницу, либо только графику

    То что предложил MS не работает
    _ttp://support.microsoft.com/kb/222064/

    12.01.2007, 10:02 #2
    12.01.2007, 10:21 #3

    В captcha.php уже самому стартовать сессию (если идентификатор хранится в куках) то и передавать ничего не надо, генерить и отдавать картинку.

    А в html получится

    12.01.2007, 10:47 #4

    tulp, отдавайте сриптом, геренящим капчу, такие заголовки:

    12.01.2007, 10:53 #5
    bondarev.pp.ru
    Посмотреть профиль
    Посетить домашнюю страницу bondarev.pp.ru
    Найти ещё сообщения от bondarev.pp.ru

    bondarev.pp.ru именно так уже и решили
    Тема закрыта

    12.01.2007, 11:03 #6

    Непонятно только зачем все так сложно. Браузер кроме прочего может и наплевать на заголовки сервера и сделать по своему, или прокси-сервер стоящий по пути может заголовки порезать или вообще заменить своими.

    Наиболее надежное решение (требующее правда javascript включенного, но это 99.9% браузеров) — в ссылке передавать случайный параметр.

    То есть ссылка должна быть вида , генерируется одной строкой яваскрипта типа

    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL
    12.01.2007, 14:07 #7