¿Cómo funciona URLConnection.setUseCaches() en la práctica?

Question

Tengo un applet que está cargando imágenes a través de una conexión http utilizando URLConnection. Estoy configurando setUseCaches (verdadero) para todas las conexiones, pero aún no veo ningún comportamiento de almacenamiento en caché. Los encabezados HTTP de mi imagen tienen una configuración de caché razonable. Si nos fijamos en bug 4528599 existe este lugar misterioso declaración:

La versión actual (1.3.1) de Java Plug-in sólo comprueba la caché del navegador para archivos cuyos nombres terminan en .jar o .class. Me han dicho que para Java Plug-In 1.4, la caché del navegador se comprobará para el siguiente archivo tipos: .class, .jar, .zip, .jpg, .gif, .wav, .au.

Por supuesto, esto se marcó como FIXED para 1.6, pero incluso en 1.6 no veo ningún almacenamiento en caché. Mis imágenes son archivos PNG y, en algunos casos, en realidad no terminan con la extensión .png. No veo ningún almacenamiento en caché.

El informe de corrección de errores habla sobre el motor de descarga 1.6, pero Google parece no saber mucho al respecto.

Se supone que funciona o simplemente es otra "característica" rota de Sun. ¿Hay alguna forma o solución alternativa en la que pueda obtener mi applet para cargar imágenes PNG desde el caché del navegador? Preferiría no implementar mi propio ...

ACTUALIZACIÓN: El almacenamiento en caché parece estar relacionado con la implementación ResponseCache. Consulte this technote para obtener más información sobre cómo funciona. La última línea dice:

No hay una implementación predeterminada de caché de URLConnection en el Java 2 Standard Edition. Sin embargo, Java Plugin y Java WebStart do proporcionan uno de la caja.

Me parece que la pregunta realmente se convierte en: ¿Cómo funciona realmente la implementación de ResponseCache de Java Plugin? ¿Cuáles son las diferencias entre v1.4/v1.5/v.16

¿Alguien tiene alguna idea?

Answer 1

Este método muy probablemente solo establezca las directivas de encabezado HTTP Cache-Control en la solicitud saliente a valores que permitan el almacenamiento en caché. Si hubiera llamado a setUseCaches (falso), habría una directiva

Cache-Control: no-cache 

por ejemplo. Para comprobar esto, puede colocar un servidor proxy de depuración HTTP entre su applet y el servidor y echar un vistazo a los encabezados.

Ahora, simplemente porque la solicitud dice que está dispuesto a usar cachés, su servidor podría no estar configurado para habilitarlos. Tal vez no establezca un encabezado Expires con un tiempo apropiadamente largo en la respuesta, o quizás esté configurando un encabezado Cache-Control en la respuesta que prohíbe el almacenamiento en caché.

Algunas otras cosas para comprobar:

• https respuestas no se almacenan en caché;
• Es posible que no tenga un caché HTTP entre el cliente y el servidor;
• El único caché HTTP es el caché del navegador, pero puede estar deshabilitado o configurado para usar muy poco disco.

Si esto fuera sólo una prueba de navegador de vanilla para la aplicación web, también querrá asegurarse de no estar presionando el botón Actualizar, ya que eso equivale a establecer no-caché.

Answer 2

La clase abstracta URLConnection proporciona los métodos set/getUseCaches, que puede ser utilizado por cualquier subclase. Sin embargo, hasta donde he podido determinar, la clase HttpURLConnection no usa esos campos de ninguna manera. Establecer el valor en verdadero o falso no tendrá ningún comportamiento diferente.

Si desea agregar un comportamiento http cache, puede hacerlo usted mismo (escribir su propio, o extender HttpURLConnector; o el uso de sockets), o intente utilizar los If-Modified-Since y If-None-Match cabeceras y buscar un código de estado 304 (No Modificado). La segunda opción es probablemente la más fácil y obtendrá los mejores resultados.