2

我完全被难住了。为了完整起见，我会给出背景，但我不确定它是否有帮助。我正在运行一个 Lift 实例的标准 Jetty 设置上运行 Lift 项目。Mac OS X。

我有一个片段可以转换 XML 输入，呈现图像，将其保存到 webroot/images/ 目录下的磁盘，文件名取自内容的 MD5，例如“c5669d3eedcf7d305dcf9f88a61b3ee0.png”。然后，该片段返回一个 img 标签，其中包含对生成图像的引用，以包含在输出中。

大多数情况下，大多数图像都有效。但大多数情况下，有些不是，有些图像不是由浏览器呈现的。尝试在浏览器（Camino 和 Firefox）中查看有问题的图像不起作用：图像未显示，这表明存在隐约错误。

在另一个浏览器（Safari 和 QuickTime）中查看它，图像工作正常。下载并打开图像工作正常。直接使用 Camino（即 file://...）查看文件时，图像显示正常：文件本身没有明显损坏。

它不能是文件名的长度，因为所有文件名都是相同的 37 个字符。

我只能假设通过 Jetty 服务时图像的传输出现问题。

确实失败的 URI 始终失败，它不是间歇性的。重启Jetty没有什么区别，所以我认为不是文件是在服务器启动后创建的。此外，渲染是一个阻塞调用，因此在发送 HTML 并且浏览器请求图像之前，文件不可能仍然打开/尚未保存。

我唯一能想象的是 MIME 类型被破坏了，所以我在 web.xml 中放置了适当的映射，但仍然没有雪茄。MIME 类型看起来没问题，我已经验证了字节数是正确的。

对于问题图像：

HTTP/1.1 200 正常
过期：1970 年 1 月 1 日星期四 00:00:00 GMT
设置 Cookie：JSESSIONID=1dbeh8eq4mtu0；路径=/
内容类型：图片/png
内容长度：25488
最后修改时间：2009 年 7 月 25 日星期六 15:38:19 GMT
服务器：码头（6.1.16）

为了完整起见，来自加载正常的图像的标题：

HTTP/1.1 200 正常
过期：1970 年 1 月 1 日星期四 00:00:00 GMT
设置 Cookie：JSESSIONID=15dt649lzovc4;Path=/
内容类型：图片/png
内容长度：18657
最后修改时间：2009 年 7 月 25 日星期六 15:41:35 GMT
服务器：码头（6.1.16）

对此非常非常不解。有什么线索吗？

干杯

乔

4

3 回答 3

1

I'm not sure if you're testing the URLs later from curl/wget, or using a packet sniffer to get the headers, but just in case its the former. I'd try using a tool such as HTTPScoop to verify that the actual data sent to Firefox fits with the expected data.

Only thing that strikes me is the difference in size. Is it generally larger images that fail? If so I'd say its some sort of broken buffering / flushing of the file.

于 2009-09-23T18:09:50.463 回答
1

我有类似的问题。在我看来，Jetty 似乎将图像视为文本，并尝试将其编码为 UTF-8。我制作了只包含 7 位数据的测试数据，它工作得很好，但是当数据包含一个设置了第 8 位的字节时，它会像 UTF-8 编码一样转换为多个字节。

由于 PNG 文件总是以字节 0x89、0x50、0x4e、0x47 开头，当由损坏的 Jetty 设置提供服务时，第一个 0x89 将转换为 0xef、0xbf、0xbd。这是 UTF-8 代码 0xfffd，AFAIK 的意思是“错误的 UTF 字符”之类的。

我认为它必须是环境中的东西，因为相同的设置适用于我自己的 Mac 和 Linux 机器，但在其他 Linux 机器和一台 Windows 机器上经常失败。

于 2009-11-13T09:17:49.900 回答
0

你是用 JAR 服务的吗？我有同样的问题，但仅适用于具有透明层的 PNG，并且仅在从 JAR 中提供时。如果我对其进行卷曲，它会立即弹出 100%，但会继续“下载”，直到达到 30 秒超时。

于 2013-07-30T06:01:05.440 回答