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

问题描述

URLConnection缓存API的描述表示为最后一句话：

在Java 2 Standard Edition中没有URLConnection缓存的默认实现。但是，Java Plugin和Java WebStart确实提供了一个开箱即用的功能。

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

• 哪个版本的Webstart可以在哪些平台上激活缓存？


• 在哪些情况下有效？仅HTTP Get？


• 可以配置吗？


• 源代码可用吗？

---

背景：

具有以下（常规）代码

  def url = new URL（'http://repo1.maven.org / maven2 /'）
 def连接= url.openConnection（）
 def结果= connection.inputStream.text 
  

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

  Java Web Start 10.9.2.05 
 JRE-Version版本1.7.0_09-b05 Java HotSpot（ TM）客户端VM 
  

行为不同。第一次执行代码时，将与服务器联系。该代码的所有后续执行均不涉及与服务器的任何通信（使用wireshark进行跟踪）。

但是它变得更加陌生。重新启动Webstart应用程序后，首次执行代码时，请求URL http://repo1.maven.org/maven2/.pack.gz 产生 404 。仅请求原始URL导致 304未修改。所有后续执行不涉及与服务器的任何通信。

我认为使用缓存功能透明地增强urlconnection的方法很好，并且可以改善客户端的性能。应用程序。但是由于服务器在这种情况下没有定义Expires标头或缓存控制标头，因此我认为上面的代码应始终询问服务器，而不应静默忽略我的请求。

案例2

在使用webstart 10.1.1.255执行时，以下代码不起作用（这是由Java 7的某些早期Beta版本安装的，但我没有知道这是哪一个）

  URL url = new URL（ http://repo1.maven.org/maven2/ ）; 
 URLConnection连接= url.openConnection（）; 
 connection.setRequestProperty（ Accept-Encoding， gzip）; 
 connection.connect（）; 
 InputStream是= connection.getInputStream（）; 
 if（ gzip .equalsIgnoreCase（connection.getContentEncoding（）））
 {
 is = new GZIPInputStream（is）; 
} 
 is.close（）; 
  

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

  java.io.IOException：不是GZIP格式的
，位于java.util.zip.GZIPInputStream.readHeader（未知源）
在java.util.zip.GZIPInputStream。 / pre> 
 
 
同时具有 Java Web Start 1.6.0_24 和现在的 Java Web Start 10.2 .1.255 我无法重现该问题。
 
 
 
通过Wireshark，我看到在出现错误的情况下，http标头包含一个If-Modified-Since条目，因此返回代码为304。在其他情况下，则没有If-Modified-Since。因此，我认为缓存在webstart的稳定版本中不起作用-尽管有上述链接的最后一句话。
 
 
 
似乎，beta版本的缓存确实对http get请求进行了调优：它确实使用If-Modified-Since并自动尝试使用gzip编码-即使客户端代码未设置此标头也是如此。但是当命中缓存时，返回的流不会被压缩，尽管 getContentEncoding 返回 gzip。 
 
 
 
由于在我的计算机上稳定的Webstart版本中缓存似乎未激活，因此我无法验证该错误是否已存在于代码中，因此犹豫要归档错误报告。 
解决方案
我到目前为止发现的唯一信息是在 JDK 7中Java Java Internet应用程序的增强功能 
 
 
默认情况下启用缓存：默认情况下，现在启用了在Web Start模式下运行的应用程序代码的网络内容的缓存。这样可以提高应用程序的性能，并提高与applet执行模式的一致性。为确保使用最新的内容副本，应用程序可以使用 URLConnection.setUseCaches（false）或请求标头Cache-Control值无缓存/无存储。
 
 
 [...] 
 
 
使用gzip编码处理内容的改进：部署缓存将使应用程序内容保持压缩形式，并使用HTTP标头中的gzip content-encoding将其按原样返回给应用程序。这使行为在不同的执行模式（第一次启动与随后的启动，启用缓存与禁用缓存）之间更加一致。有关更多详细信息，请参见 6575586 。
 
 
 
The description of the URLConnection caching API states as the last sentence:

  
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.
Where can I find more information about the Webstart ResponseCache? 


Which Versions of Webstart on which platforms activate Caching? 
In which cases is it active? Only HTTP Get?
Can it be configured?
Is the sourcecode available?




Background:

Case 1

With following (groovy) code 
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
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). 

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.

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.

Case 2

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();
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)
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.

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.

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". 

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. 
解决方案
The only information I have found so far is at Java Rich Internet Applications Enhancements in JDK 7

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.
[...]
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屋！