как очистить или заменить кэшируемое изображение

Если Вы пишете страницу динамично, можно добавить измененную в последний раз метку времени к URL:

<img src="image.jpg?lastmod=12345678" ...

, Если изображение повторно загружается, там способ ОЧИСТИТЬ или ЗАМЕНИТЬ ранее кэшируемое клиентское изображение? В моем примере выше, цель состоит в том, чтобы заставить браузер забыть то, что "42.jpg"

, Вы выполняете право Firefox?

• Находят Tools, Выбор Меню
• Clear Private Data
• Удаляет галочку у всех флажков кроме, удостоверяются Cache, Проверяется
• , Нажимают OK

:-)

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

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

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

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

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

Следовательно, необходимо рассматривать каждый файл и каждый URL как драгоценный ресурс, которым нужно управлять тщательно.

Поэтому предложение porneL управления версиями файлы изображений, кажется, лучший долгосрочный ответ. ЗАВЕРШАЮЩИЙ ТЕГ используется при нормальных обстоятельствах, но возможно Ваши усилия аннулировали его? Попытайтесь изменить ЗАВЕРШАЮЩИЙ ТЕГ, как предложено.

Причина? прием x=timestamp используется, то, потому что это - единственный способ сделать это на на основание изображения. Это или динамично генерирует названия картинки и указывает на приложение, это производит изображение.

я предлагаю, чтобы Вы выяснили, сторона сервера, если изображение было изменено/обновлено, и раз так тогда производило Ваш тег с? x=timestamp обманывают для принуждения нового изображения.

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

Измените ЗАВЕРШАЮЩИЙ ТЕГ для изображения.

<meta> абсолютно не важно. На самом деле Вы не должны пробовать, используют его для управления кэшем вообще (к тому времени, когда что-либо читает содержание документа, это уже кэшируется).

В HTTP каждый URL независим. Независимо от того, что Вы делаете к документу HTML, он не будет относиться к изображениям.

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

, Если Ваши изменения образа очень часто (каждые несколько минут, или даже по каждому запросу), то отправляют Cache-control: no-cache или Cache-control: max-age= xx , где xx является числом секунд, что изображение "ново".

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

, Если у Вас есть Apache и mod_headers или mod_expires тогда, создают .htaccess файл с соответствующими правилами.

<Files ~ "-nocache\.jpg">
   Header set Cache-control "no-cache"
</Files>

Выше сделает *-nocache.jpg файлы некэшируемый.

Вы могли также вручить изображения с помощью Сценария PHP (у них есть ужасный cachability по умолчанию;)

Начиная с большинства, если не все, ответы и комментарии здесь - копии частей вопрос, или достаточно близко, я добавлю свои 2 цента.

я просто хочу указать что, даже если существует способ, которым будет трудным реализовать. Логика его захватывает нас. От логической позиции, говоря браузеру заменить это кэшировало изображения для каждого измененного изображения в списке, так как определенная дата идеальна, НО... Когда Вы удалили бы список и как Вы будете знать, есть ли у всех последняя версия, кто посетил бы снова?

, Таким образом, мое 1-е "предложение", как OP, относительно которого попросили, является этой теорией списка.

, Как я вижу, выполнение этого:

А.) Имеют список, что могут быть сохранены наши динамические и ручные измененные URL изображения.

B.) Назначенный мертвая дата, где выгода будет сброшена и список, будет усеченной независимо.

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

C.1) Используя Iframe или запрос ajax/xhr я думаю, что Вы могли циклично выполниться через каждое изображение списка, обновляющего страницу, чтобы показать различное изображение и проверить кэш по своей собственной измененной дате. Таким образом на серверной стороне использования onload этого изображения, чтобы дешифровать, если это не последнее изображение, когда это загружается, переходят к следующему изображению.

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

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

P.S. Это - просто образованное воображение. Быстрая теория. Если/когда я сделаю его, то я отправлю финал. Вероятно, не здесь, потому что это потребует серверных сценариев. Это - по крайней мере, предложение, не упомянутое в вопросе OP, который он say's он уже попробовал.

Если изменение имени файла изображения невозможно, используйте переменную сеанса на стороне сервера и функцию javascript window.location.reload () . Как показано ниже:

После завершения загрузки:

Session("reload") = "yes"

On page_load:

If Session("reload") = "yes" Then
    Session("reload") = Nothing
    ClientScript.RegisterStartupScript(Me.GetType), "ReloadImages", "window.location.reload();", True)
End If

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

Надеюсь, это поможет.