Предотвращение кэширования определенных изображений в Silverlight

Question

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

Я пробовал пару решений здесь и здесь2

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

По сути, я отображаю изображения двумя разными способами.

1) Я беру строку и передаю ее в источник <Image />

2) Я превращаю строку в URI и превращаю ее в растровое изображение за кулисами, которое затем передается в источник <Image />

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

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

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

Кто-нибудь знает, как выборочно прекратить кэширование?

Answer 1

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

например. http://www.example.com/myimage.jpg?ts=2011081107333454

Answer 2

Сначала давайте проясним несколько неоднозначный термин «кеширование».

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

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

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

Если затем приложение решает поддерживать свой собственный "кэш" URI для ресурсовзапрошенный из стека HTTP, не требуется реализовывать HTTP-совместимые алгоритмы кэширования.Если такой «кеш» запрашивается для предоставления конкретного объекта приложения, соответствующего указанному Uri, это совершенно бесплатно сделать без ссылки на HTTP.

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

Предложение Ulitmately Robs имеет смысл в этом случае, когда вы «версии» uri со значением строки запроса.Однако речь идет не о предотвращении кэширования, а о кэшировании как на уровне приложения, так и на уровне http - это хорошо, а о том, чтобы обеспечить ресурс, на который ссылается полный Uri, всегда желаемый контент.