Как URLConnection.setUseCaches () работает на практике? - PullRequest
Новая
       24

Как URLConnection.setUseCaches () работает на практике?

18 голосов
/ 26 августа 2009

У меня есть апплет, который загружает изображения через http-соединение, используя URLConnection. Я устанавливаю setUseCaches (true) для всех соединений, но все еще не вижу никакого поведения кэширования. Заголовки HTTP моего изображения имеют разумные настройки кэша. Если вы посмотрите на bug 4528599 , то есть довольно загадочное утверждение:

Текущая версия (1.3.1) подключаемого модуля Java проверяет только кэш браузера на наличие файлы, имена которых заканчиваются на .jar или .class. Мне сказали, что для Java Plug-In 1.4 Кэш браузера будет проверен на наличие следующего файла типы: .class, .jar, .zip, .jpg, .gif, .wav, .au.

Конечно, это было помечено как FIXED для 1.6, но даже под 1.6 я не вижу никакого кеширования. Мои изображения - это файлы PNG, и в некоторых случаях они не заканчиваются расширением .png. Я не вижу никакого кеширования.

В отчете об исправлении ошибки рассказывается о движке 1.6 Unified Download Engine, но Google, похоже, об этом мало что знает.

Это должно сработать или это просто еще одна "особенность" сломанного Солнца. Есть ли способ или обходной путь, где я могу получить мой апплет для загрузки изображений PNG из кэша браузера? Я бы предпочел не реализовывать свои собственные ....

ОБНОВЛЕНИЕ: Кэширование, похоже, связано с реализацией ResponseCache . См. этот technote для получения дополнительной информации о том, как это работает. Последняя строка говорит:

В кэшировании URLConnection по умолчанию нет реализации Java 2 Standard Edition. Тем не менее, плагин Java и Java WebStart делают предоставить один из коробки.

Так что мне кажется, что на самом деле возникает вопрос: как в действительности работает реализация Java Plugin ResponseCache? Каковы различия между v1.4 / v1.5 / v.16

У кого-нибудь есть идеи?

Ответы [ 2 ]

7 голосов
/ 26 августа 2009

Скорее всего, этот метод только устанавливает директивы заголовка HTTP Cache-Control в исходящем запросе на значения, которые разрешают кэширование. Если бы вы вызвали setUseCaches (false), было бы 

Cache-Control: no-cache
Директива

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

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

Что еще нужно проверить:

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

Если бы это был простой тест браузера с веб-приложением, вы бы также хотели убедиться, что вы не нажимаете кнопку обновления, поскольку это эквивалентно установке no-cache.

4 голосов
/ 26 августа 2009

Абстрактный класс URLConnection предоставляет методы set / getUseCaches, которые могут использоваться любыми подклассами. Однако, насколько мне удалось определить, класс HttpURLConnection не использует эти поля никоим образом. Установка значения в true или false не будет иметь другого поведения.

Если вы хотите добавить режим кэширования http, вы можете сделать это самостоятельно (написать свой собственный или расширить HttpURLConnector или использовать сокеты) или попробовать использовать If-Modified-Since и If-None-Match заголовки и ищите код состояния 304 (не изменен). Второй вариант, вероятно, самый простой и даст вам лучшие результаты.

...