Java Webstart 和 URLConnection 缓存 API [英] Java Webstart and URLConnection caching API

问题描述

URLConnection缓存API的说明 陈述为最后一句话:

Java 2 标准版中没有 URLConnection 缓存的默认实现.但是，Java Plugin 和 Java WebStart 确实提供了一个开箱即用的插件.

There is no default implementation of URLConnection caching in the Java 2 Standard Edition. However, Java Plugin and Java WebStart do provide one out of the box.

在哪里可以找到有关 Webstart ResponseCache 的更多信息?

Where can I find more information about the Webstart ResponseCache?

• 在哪些平台上激活缓存的哪些版本的 Webstart?
• 它在哪些情况下处于活动状态?仅 HTTP 获取?
• 可以配置吗?
• 源代码是否可用?

使用以下(常规)代码

def url = new URL('http://repo1.maven.org/maven2/')
def connection = url.openConnection()
def result = connection.inputStream.text

我希望每次执行代码时都会联系服务器.但是在

I would expect that every time the code is executed the server is contacted. But when executed in

Java Web Start 10.9.2.05
JRE-Version verwenden 1.7.0_09-b05 Java HotSpot(TM) Client VM

行为不同.第一次执行代码时，会联系服务器.代码的所有后续执行不涉及与服务器的任何通信(使用wireshark 进行跟踪).

the behavior is different. The first time the code is executed, the server is contacted. All subsequent executions of the code don't involve any communication to the server (traced using wireshark).

但它变得更奇怪了.重新启动 webstart 应用程序后，第一次执行代码时，请求 url http://repo1.maven.org/maven2/.pack.gz 导致 404.只有原始 url 被请求导致 304 NOT MODIFIED.所有后续执行不涉及与服务器的任何通信.

But it gets even stranger. After re-start of the webstart app, the first time the code is executed, the url http://repo1.maven.org/maven2/.pack.gz is requested resulting in a 404. Only than the original url is requested resulting in a 304 NOT MODIFIED. All subsequent executions don't involve any communication to the server.

我认为通过缓存功能透明地增强 urlconnection 的方法很好而且很好，有助于提高客户端应用程序的性能.但是因为在这种情况下服务器没有定义一个 Expires 标头，也没有定义一个缓存控制标头，我认为上面的代码应该总是询问服务器而不是默默地忽略我的请求.

I think the approach of transparently enhancing the urlconnection with caching capabilities is nice and fine and helps improve performance of client applications. But since the server in this case didn't define an Expires header nor a cache-control header, I think the code above should always ask the server and not silently ignore my request.

以下代码在使用 webstart 10.1.1.255 执行时不起作用(这是由 Java 7 的一些早期测试版安装的，但我不知道这是哪个)

Following code does not work when executed with webstart 10.1.1.255 (this was installed by some early beta Version of java 7, but I don't know which one this was)

URL url = new URL("http://repo1.maven.org/maven2/");
URLConnection connection = url.openConnection();
connection.setRequestProperty("Accept-Encoding", "gzip");
connection.connect();
InputStream is = connection.getInputStream();
if ("gzip".equalsIgnoreCase(connection.getContentEncoding()))
{
    is = new GZIPInputStream(is);
}
is.close();

使用 Java Web Start 10.1.1.255 从第二次执行开始，我得到了一个

With Java Web Start 10.1.1.255 starting with the second execution I got a

java.io.IOException: Not in GZIP format
    at java.util.zip.GZIPInputStream.readHeader(Unknown Source)
    at java.util.zip.GZIPInputStream.<init>(Unknown Source)
    at java.util.zip.GZIPInputStream.<init>(Unknown Source)

使用 Java Web Start 1.6.0_24 和现在的 Java Web Start 10.2.1.255 我无法重现该问题.

With both Java Web Start 1.6.0_24 and now Java Web Start 10.2.1.255 I am not able to reproduce the problem.

在 Wireshark 中，我看到在出现错误的情况下，http 标头包含一个 If-Modified-Since 条目，因此返回代码为 304.在其他情况下，没有 If-Modified-Since.因此，我认为缓存在 webstart 的稳定版本中并不活跃——尽管上面链接的最后一句是.

With Wireshark I saw that in the case where I got the error, the http header contained an If-Modified-Since entry, and the return code therefore was 304. In the other cases there was no If-Modified-Since. Therefore I think that caching is not active in the stable versions of webstart -- despite the last sentence of the above link.

看起来，测试版的缓存对 http get 请求进行了积极的调整:它确实使用了 If-Modified-Since 并自动尝试使用 gzip 编码——即使客户端代码没有设置这个标头.但是当缓存被命中时，返回的流不会被 gzip，尽管 getContentEncoding 返回gzip".

It seems, that the cache of the beta version does aggressive tuning to http get requests: It does use If-Modified-Since and automatically tries to use gzip encoding -- even if the client code does not set this header. But when the cache is hit, the returned stream is not gzipped, although getContentEncoding returns "gzip".

由于缓存在我机器上的稳定版本的 webstart 中似乎不活跃，我无法再验证该错误是否存在于代码中，因此犹豫是否提交错误报告.

Since the caching seems not to be active in the stable version of webstart on my machine, I cannot verify if the bug is in the code any more and therefore hesitate to file a bug report.

推荐答案

目前我找到的唯一信息是 JDK 7 中的 Java 富 Internet 应用程序增强

The only information I have found so far is at Java Rich Internet Applications Enhancements in JDK 7

默认启用缓存:现在默认启用在 Web Start 模式下运行的应用程序代码的网络内容缓存.这允许应用程序改进性能和与小程序执行模式的一致性.为确保使用最新的内容副本，应用程序可以使用 URLConnection.setUseCaches(false) 或请求头 Cache-Control 值 no-cache/no-store.

Caching enabled by default: Caching of network content for application code running in Web Start mode is now enabled by default. This allows application improved performance and consistency with applet execution mode. To ensure the latest copy of content is used, the application can use URLConnection.setUseCaches(false) or request header Cache-Control values no-cache/no-store.

[...]

使用 gzip 编码处理内容的改进:部署缓存将以压缩形式保存应用程序内容，并在 HTTP 标头中使用 gzip 内容编码将其原样返回给应用程序.这使得不同执行模式下的行为更加一致(首次启动与后续启动、缓存启用与缓存禁用).有关详细信息，请参阅 6575586.

Improvements for handling content with gzip encoding: The deployment cache will keep application content in compressed form and return it to the application as-is with gzip content-encoding in the HTTP header. This makes behavior more consistent across different execution modes (first launch versus subsequent launch, cache enabled versus cache disabled). See 6575586 for more details.

这篇关于Java Webstart 和 URLConnection 缓存 API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！