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

Scott Hanselman отправил некоторое время назад [приблизительно 110] установку OpenID в .net.

9
задан alpav 19 February 2010 в 04:54
поделиться

7 ответов

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

3
ответ дан 3 November 2019 в 01:02
поделиться

Я не думаю, что то, что вы предлагаете, необходимо или желательно.

Кэш на стороне клиента должен контролироваться пользователем, а не вами (поставщиком данных / кода). Если пользователю нужен лучший способ управления своими «Временными Интернет-файлами», это зависит от разработчиков браузера, но я думаю, вы не должны иметь права голоса в том, как им управлять.

Для всех намерений и целей вам нужно только сказать: «эти данные / код можно использовать до даты X», «эти данные / код можно использовать до версии Y» или «они больше никогда не будут использоваться».

Отличные стратегии управления кешем уже можно настроить с помощью существующих заголовков HTTP (Cache-Control, ETag и т. Д.). Если вы хотите, чтобы что-то было «принудительно» обновлено, вы всегда можете добавить строку запроса с датой на ней. На самом деле это не взлом, как вы предлагаете, потому что вы говорите: «Дайте мне версию файла на эту дату» ... и у вашего сервера есть вся свобода в мире, чтобы обновить политику кэширования: return " 302 перенаправить "на версию без строки запроса или отправить новые заголовки и т. Д.

Изменить :

Я могу уточнить свою идею сверху:

Вы можете использовать путь или строку запроса, чтобы идентифицировать "текущая" версия:

http://somedomain.com/somepath/current/yourfile.js

"Текущий" URL-адрес может быть настроен для перенаправления 302 на конкретную версию yourfile.js,

0
ответ дан 3 November 2019 в 01:02
поделиться

Hehe, well, as far as us developers are concerned, of course!

On the other hand, cache is there to facilitate the user's experience in terms of responsiveness. It is our responsibility to work-around all these nuisances and protect the user in a shell of ignorance and all-is-wellness.

5
ответ дан 3 November 2019 в 01:02
поделиться

It's an interesting idea, but how would the browser know when to ask your website if it should clear the cache? Every time the page is loaded? Wouldn't that partially defeat the purpose of caching? Set reasonable cache expiration intervals, and schedule your updates to match those, and it should be ok as it is.

2
ответ дан 3 November 2019 в 01:02
поделиться

I don't think what you suggest is necessary or desirable.

The client-side cache should be controlled by the user, not by you (the data/code provider). If the user wants a better way to manage his "Temporary Internet Files", then that's up to the browser developers, but I think you should not have a say in how it is managed.

For all intents and purposes, you only need to say, "this data/code is usable until X date", "this data/code is usable until Y version", or "it's never usable again".

Excellent cache control strategies can already be setup by using the existing HTTP headers (Cache-Control, ETag, etc.). If you want something to be "forced" to be refreshed, you can always add a querystring with the date on it. This is not really a hack, as you suggest, because you are saying, "get me the version of the file as of this date"... and your server has all the freedom in the world to refresh the caching policy: return "302 redirect" to the non-querystring version, or send down new headers, etc.

Edit:

I can refine my idea from above:

You can use a path or querystring to identify the "current" version:

http://somedomain.com/somepath/current/yourfile.js

The "current" URL can be setup to give a 302 redirect to a particular version of yourfile.js, while also telling the browser never to cache the current version:

302 Moved Temporarily
Location: /somepath/v3.2.3/yourfile.js
Cache-Control: no-cache;

This allows your "loader" HTML to include Javascript that decides to use a certain version:

<script type="text/javascript">
<%php
   if($action == "clearCache") {
        print "var version = 'current';";
   } else {
        print "var version = '" . $version . "';";
   }
%>
</script>
1
ответ дан 3 November 2019 в 01:02
поделиться

they theorically do, with cache params in the header section and meta parameters (google meta no-cache, PHP/ASP no-cache) like cache-expires, the date that should expire etc

I agree that this is weird in most, if not all, browsers. иногда это работает, иногда нет или требуется больше времени для очистки кеша по какой-то причине

, но было бы неплохо иметь эту опцию в скрипте, например, javascript или что-то прямо в тегах, например img src = " blah.jpg "expires =" my_blah_last_edited "

могло бы быть лучше, правда

0
ответ дан 3 November 2019 в 01:02
поделиться

I imagine there are great security concerns. You have anonymous and remote web-pages telling local a client to delete files on the client machine - this has all sorts of potential for disaster. Would you trust IE to do this? It just sounds too risky. There's a big difference between a directive to not cache something in the first place and a directive to delete something already in existence from the cache.

0
ответ дан 3 November 2019 в 01:02
поделиться
Другие вопросы по тегам:

Похожие вопросы: