Я смущен кэшированием HTTP
В вашем коде есть логическая проблема, так как он не может просто распознать 'not ' (обратите внимание на пробел) как причудливое слово.
Вы можете изменить свою if логику и использовать вместо этого регулярное выражение.
if (str.matches(".*\\bnot\\b.*")) {
output.append(REAL_FANCY);
} else {
output.append(REGULARLY_FANCY);
}
Здесь шаблон регулярного выражения соответствует целому слову , а не только . Подробное объяснение этого регулярного выражения можно найти в здесь .
5 ответов
Серверы кэширования, как предполагается, делают недействительным объект, упомянутый URI по получении ПОМЕЩЕННОГО (но как Вы заметили, это не покрывает все случаи).
Кроме этого Вы могли использовать заголовки управления кэшем на своих ответах, чтобы ограничить или предотвратить кэширование и попытаться обработать заголовки запроса, которые спрашивают, был ли URI изменен, так как в последний раз выбрано.
Это - все еще действительно сложная проблема и на самом деле все еще работается на (например, см. http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p6-cache-05.txt),
Кэширование в прокси действительно не применяется, если содержание шифруется (по крайней мере, с SSL), так, чтобы не должна была быть проблема (все еще может быть проблема о клиенте хотя).
Протокол HTTP поддерживает тип запроса под названием "If-Modified-Since", который в основном позволяет кэширующемуся серверу спрашивать веб-сервер, если объект изменился. Протокол HTTP также поддерживает заголовки "Управления Кэша" в ответах сервера HTTP, которые говорят серверы кэширования, что сделать с содержанием (такой, поскольку никогда не кэшируют это или предполагают, что это истекает за 1 день, и т.д.).
Также Вы упомянули зашифрованные ответы. Серверы кэширования HTTP не могут кэшировать SSL, потому что сделать так потребовало бы, чтобы они дешифровали страницы как "человек в середине". Выполнение так технически бросило бы вызов (дешифруйте страницу, сохраните ее и повторно зашифруйте ее для клиента), и также нарушил бы безопасность страницы, вызывающую "недопустимый сертификат" предупреждения на стороне клиента. Технически возможно иметь сервер кэширования, делают это, но это вызывает больше проблем, чем это решает и является плохой идеей. Я сомневаюсь, что любые серверы кэширования на самом деле делают этот тип вещи.
К сожалению, кэширование HTTP основано на точном URIs, и Вы не можете достигнуть разумного поведения в своем случае, не вынуждая клиенты сделать придание вновь юридической силы кэша.
Если Вы имели:
GET /farm/123
POST /farm_update/123
Вы могли использовать Content-Location заголовок, чтобы указать, что второй запрос изменил первый. AFAIK Вы не можете сделать этого с несколькими URIs и я не проверил, работает ли это вообще в популярных клиентах.
Решение состоит в том, чтобы заставить страницы истечь быстро и дескриптор If-Modified-Since или E-Tag с 304 Not Modified состояние.
Вы не можете кэшировать динамический контент (withouth недостатки), потому что... это динамично.
В ре: ответ SoapBox:
Я думаю
If-Modified-SinceдвухэтапноеGETЯ предложил в конце своего вопроса. На решение OK походит, где содержание является большим (т.е. где стоимость удвоения количества запросов и таким образом издержек преодолена усилениями не повторной отправки содержания. Это не верно в моем примере Ферм, так как информация каждой Фермы коротка.)Совершенно разумно создать систему, которая отправляет зашифрованное содержимое по незашифрованному (HTTP) канал. Вообразите сценарий Сервис-ориентированной архитектуры, где обновления являются нечастыми и
GETs (a) частыми, (b) потребностью быть чрезвычайно быстрыми и (c) должен быть зашифрован. Вы создали бы сервер, который требует aFROMзаголовок (или, эквивалентно, ключ API в параметрах запроса), и передает асимметрично зашифрованную версию обратно содержания для запрашивающей стороны. Асимметричное шифрование является медленным, но, если правильно кэшируется, бьет объединенное квитирование SSL (асимметричное шифрование) и симметричное шифрование содержания. Добавление кэша перед этим сервером существенно убыстрилось быGETs.Кэширующийся сервер мог обоснованно кэшироваться, HTTPS ДОБИРАЕТСЯ в течение короткого промежутка времени. Мой банк мог бы поместить управление кэша приблизительно 5 минут на моей домашней странице учетной записи и недавних транзакциях. Я, ужасно вероятно, не проведу долгое время на сайт, таким образом, сессии не будут очень длинны, и я, вероятно, закончу тем, что поражал основную страницу своей учетной записи несколько раз, в то время как я ищу ту проверку, я недавно отправил в SnorgTees.