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

UDFRegistration.register поставляется в вариантах, которые принимают:

[1128 ] Не существует варианта, который принимает имя класса. Ваш код не терпит неудачу при компиляции только потому, что String в Scala равно (Int) => Char, поэтому соответствует

def register[RT, A1](name: String, func: (A1) ⇒ RT)(implicit arg0: scala.reflect.api.JavaUniverse.TypeTag[RT], arg1: scala.reflect.api.JavaUniverse.TypeTag[A1]): UserDefinedFunction

Но это, конечно, не то, что вы имеете в виду.

115
задан Benjamin 13 August 2013 в 10:40
поделиться

6 ответов

no-store should not be necessary in normal situations, and can harm both speed and usability. It is intended for use where the HTTP response contains information so sensitive it should never be written to a disk cache at all, regardless of the negative effects that creates for the user.

How it works:

  • Normally, even if a user agent such as a browser determines that a response shouldn't be cached, it may still store it to the disk cache for reasons internal to the user agent. This version may be utilised for features like "view source", "back", "page info", and so on, where the user hasn't necessarily requested the page again, but the browser doesn't consider it a new page view and it would make sense to serve the same version the user is currently viewing.

  • Using no-store will prevent that response being stored, but this may impact the browser's ability to give "view source", "back", "page info" and so on without making a new, separate request for the server, which is undesirable. In other words, the user may try viewing the source and if the browser didn't keep it in memory, they'll either be told this isn't possible, or it will cause a new request to the server. Therefore, no-store should only be used when the impeded user experience of these features not working properly or quickly is outweighed by the importance of ensuring content is not stored in the cache.

My current understanding is that it is just for intermediate cache server. Even if "no-cache" is in response, intermediate cache server can still save the content to non-volatile storage.

This is incorrect. Intermediate cache servers compatible with HTTP 1.1 will obey the no-cache and must-revalidate instructions, ensuring that content is not cached. Using these instructions will ensure that the response is not cached by any intermediate cache, and that all subsequent requests are sent back to the origin server.

If the intermediate cache server does not support HTTP 1.1, then you will need to use Pragma: no-cache and hope for the best. Note that if it doesn't support HTTP 1.1 then no-store is irrelevant anyway.

11
ответ дан 24 November 2019 в 02:26
поделиться

Originally we used no-cache many years ago and did run into some problems with stale content with certain browsers... Don't remember the specifics unfortunately.

We had since settled on JUST the use of no-store. Have never looked back or had a single issue with stale content by any browser or intermediaries since.

This space is certainly dominated by reality of implementations vs what happens to have been written in various RFCs. Many proxies in particular tend to think they do a better job of "improving performance" by replacing the policy they are supposed to be following with their own.

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

При определенных обстоятельствах IE6 по-прежнему будет кэшировать файлы, даже если в заголовках ответа указано Cache-Control: no-cache .

Состояния W3C для no-cache :

Если директива no-cache не работает укажите имя поля, затем кеш НЕ ДОЛЖНЫ использовать ответ для удовлетворения последующий запрос без успешного повторная проверка с исходным сервером.

В моем приложении, если вы посетили страницу с заголовком no-cache , затем вышли из системы, а затем вернулись в свой браузер, IE6 все равно захватит страницу из кеш (без нового / проверяющего запроса к серверу). Добавление в заголовок no-store остановило его выполнение. Но если вы поверите W3C на слове, на самом деле нет никакого способа контролировать это поведение:

Буферы истории МОГУТ хранить такие ответы как часть своей нормальной работы.

Описываются общие различия между историей браузера и обычным HTTP-кешированием. в конкретном подразделе спецификации .

46
ответ дан 24 November 2019 в 02:26
поделиться

Из спецификации HTTP 1.1 :

no-store :

Целью директивы no-store является для предотвращения непреднамеренного выпуска или сохранения конфиденциальной информации (например, на лентах с резервными копиями). Директива no-store применяется ко всему сообщению и МОЖЕТ быть отправлена ​​либо в ответе, либо в запросе. Если отправлено в запросе, кэш НЕ ДОЛЖЕН хранить какую-либо часть этого запроса или любого ответа на него. При отправке в ответе кэш НЕ ДОЛЖЕН хранить какую-либо часть этого ответа или запроса, который его вызвал. Эта директива применяется как к общим, так и к общим кешам. «НЕ ДОЛЖЕН хранить» в этом контексте означает, что кэш НЕ ДОЛЖЕН намеренно хранить информацию в энергонезависимой памяти, Даже если эта директива связана с ответом, пользователи могут явно сохранить такой ответ вне системы кэширования (например, с помощью диалогового окна «Сохранить как»). Буферы истории МОГУТ хранить такие ответы как часть своей нормальной работы. Цель этой директивы - удовлетворить заявленные требования определенных пользователей и авторов сервисов, которые обеспокоены случайным выпуском информации из-за непредвиденного доступа к структурам данных кеширования. Хотя использование этой директивы может в некоторых случаях улучшить конфиденциальность, мы предупреждаем, что это ни в коем случае НЕ является надежным или достаточным механизмом для обеспечения конфиденциальности. В частности, вредоносные или скомпрометированные кеши могут не распознавать эту директиву или не подчиняться ей, а сети связи могут быть уязвимы для подслушивания.

16
ответ дан 24 November 2019 в 02:26
поделиться

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

  • no-cache для IE

  • no-store для Firefox

Вот моя информация об этом:

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

13
ответ дан 24 November 2019 в 02:26
поделиться

Чтобы еще больше усугубить ситуацию, в некоторых ситуациях нельзя использовать no-cache, но no-store можно:

http://faindu.wordpress.com/2008 / 04/18 / ie7-ssl-xml-flex-error-2032-stream-error /

1
ответ дан 24 November 2019 в 02:26
поделиться
Другие вопросы по тегам:

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