openconnection - java url connection example

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

Question

Tengo un applet que carga 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 el error 4528599 hay una declaración bastante misteriosa:

La versión actual (1.3.1) del complemento de Java solo comprueba la memoria caché del navegador para los archivos cuyos nombres terminan en .jar o .class. Me han dicho que para Java Plug-In 1.4 se revisará la caché del navegador para los siguientes tipos de archivos: .class, .jar, .zip, .jpg, .gif, .wav, .au.

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

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

¿Se supone que esto funciona o simplemente es otra "característica" del Sol roto? ¿Hay alguna forma o solución alternativa en la que pueda hacer que mi applet cargue imágenes PNG desde el caché del navegador? Preferiría no implementar mi propia ....

ACTUALIZACIÓN: el almacenamiento en caché parece estar vinculado a la implementación de ResponseCache . Consulte esta nota técnica para obtener más información sobre cómo funciona. La última línea dice:

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

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

¿Alguien tiene alguna idea?

Answer 1

Es muy probable que este método solo establezca las directivas de encabezado de HTTP Cache-Control en la solicitud saliente a valores que permitan el almacenamiento en caché. Si hubieras llamado setUseCaches (falso), habría un

Cache-Control: no-cache

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

Ahora porque la solicitud dice que está dispuesto a usar cachés, es posible que su servidor no esté configurado para habilitarlos. Quizás no esté configurando un encabezado Expires con un tiempo suficientemente largo en la respuesta, o quizás esté configurando un encabezado Cache-Control en la respuesta que prohíba el almacenamiento en caché.

Algunas otras cosas para comprobar:

• Las respuestas https nunca se almacenan en caché;
• Es posible que no tenga una memoria caché HTTP entre el cliente y el servidor;
• La única caché HTTP es la caché del navegador, pero puede estar deshabilitada o configurada para usar muy poco disco.

Si esto fuera solo una prueba de navegador de la aplicación web, también querrá asegurarse de no estar presionando el botón de actualización, ya que es equivalente a configurar no-cache.

Answer 2

La clase abstracta URLConnection proporciona métodos set / getUseCaches, que pueden ser utilizados por cualquier subclase. Hasta donde he podido determinar, sin embargo, 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 el comportamiento de almacenamiento en caché de http, puede hacerlo usted mismo (escribir el suyo propio o extender HttpURLConnector o usar Sockets), o intentar usar los encabezados If-Modified-Since y If-None-Match y buscar un estado código 304 (no modificado). La segunda opción es probablemente la más fácil y le dará los mejores resultados.