Strangeness with Jetty serving images

Question

I'm completely stumped. I'll give the background for the sake of completeness but I'm not sure if it will help or not. I'm running a Lift project on a standard Jetty set-up running one Lift instance. Mac OS X.

I have a snippet which transforms the XML input, renders an image, saves it to disc under the webroot/images/ directory with a filenametaken from the MD5 of the contents, such as "c5669d3eedcf7d305dcf9f88a61b3ee0.png". The snippet then returns an img tag with a reference to the generated image for inclusion in the output.

Most of the time most of the images work. But most of the time some of them don't, and some of the images are not rendered by the browser. Attempting to view a problem image in the browser (Camino and Firefox) doesn't work: the image is not displayed, suggesting that something is vaguely wrong.

Viewing it in another browser (Safari and with QuickTime), the image works fine. Downloading and opening the image works fine. When viewing the file directly with Camino (i.e. file://...), the image shows fine: the file itself is not obviously corrupted.

It can't be the length of the filename, because all filenames are the same 37 characters.

I can only assume that something goes wrong in the transport of the image when served through Jetty.

The URIs that do fail, fail consistently, it's not intermittent. Restarting Jetty makes no difference, so I don't think it's that the file was created after the server started. Also, the render is a blocking call, so there's no chance that the file is still open / hasn't been saved before the HTML is sent and the browser requests the images.

The only thing I can imagine is that the MIME type is mangled, so I put the appropriate mapping in web.xml but still no cigar. The MIME type looks to be OK and I've verified that the number of bytes is correct.

For the problem image:

HTTP/1.1 200 OK
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=1dbeh8eq4mtu0;Path=/
Content-Type: image/png
Content-Length: 25488
Last-Modified: Sat, 25 Jul 2009 15:38:19 GMT
Server: Jetty(6.1.16)

For completeness, the headers from an image that does load fine:

HTTP/1.1 200 OK
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=15dt649lzovc4;Path=/
Content-Type: image/png
Content-Length: 18657
Last-Modified: Sat, 25 Jul 2009 15:41:35 GMT
Server: Jetty(6.1.16)

Very very puzzled about this. Any clues?

Cheers

Joe

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

Answer 2

I have similar issue. To me it looks like Jetty is treating the image as a text and it tries to encode it to UTF-8. I made test data that contains only 7-bit data and it works just fine, but when the data contains a byte that has 8th bit set, it gets converted to multiple bytes just like in UTF-8 encoding.

As the PNG files always start with bytes 0x89, 0x50, 0x4e, 0x47, when served by broken Jetty setup, the first 0x89 is converted to 0xef, 0xbf, 0xbd. This is the UTF-8 code 0xfffd, which AFAIK means "wrong UTF character", or something.

I think it has to be something in environment, as the same setup works on my own Mac and Linux boxes, but constantly fails on other Linux box and on one Windows machine.