Found in GWT Release: 1.4.10

Detailed description: When loaded over HTTPS under IE (and only IE) the ImageBundle looks like it is loading the images, but when it finishes, only the clear-cache.gif file is loaded, with the correct widths and heights of where the real images are meant to be. The end result is a blank toolbar.

I have tested this with the RichTextToolbar provided in the KitchenSink example and with my own toolbar. No amount of refreshing seems to load the images, so I don't think it's a timing thing.

Workaround if you have one: None that I can think of. I'm happy to try any workarounds that anyone can think of, just let me know.

Links to the relevant GWT Developer Forum posts:

Just some further notes on this. I notice that IE also pops up a mixed content warning, and I've traced this down to the image bundle, saying no puts empty boxes where all the ImageBundle images should be, saying yes loads clear-cache.gif but not the actual image.

I've also tried loading the image (the randomlettersandnumbers.cache.png) directly into IE, and that works - so I think it's an ImageBundle bug.

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/df1cc5943839fb3c/e7cdc75cd613c69b?lnk=gst&q=ImageBundle&rnum=1#e7cdc75cd613c69b

See attachment. I have the problem with mixed content (not failure to download images), with the tree. I narrowed that down to the ImageBundle being used in that component.

I attached my modified ClippedImageImplIE6.java, which solves the problem for me (no more mixed content warning)... maybe this fixes your image downloading issue as well ?

I believe Rajeev is already looking at this. Is this a dup of another ClippedImage-specific bug? Seems like it might be a dup of 1172.

I think you meant 1200. In my mind, no. 1200 is just about the mixed security warning. This one is about the fact that the images don't actually load.

The two may be related caused by the same bit of code, but in my mind they are two different bugs.

Ok, sorry about the multiple posts, but I've figured out why it's happening. I tried putting the kitchensink example into my secure realm (I'm running this under Glassfish) and the images dissapeared just like in my application. I then removed all of the security settings from my web.xml and it worked.

I guess the obvious question is why the ImageBundle fails, only in IE, and only in a security realm, even if you've already been authenticated. Is it doing something super fancy? I guess the other obvious question is this a bug in GWT or not?

Rusty

There have been reports of problems with using AlphaImageLoader to render images served up over SSL, and the AlphaImageLoader is exactly what we are using in the IE implementation of clipped images.

However, I ran some tests over SSL with our KitchenSink application in IE, and I was able to see the clipped images without any problems. So, it is not a general incompatibility with SSL and AlphaImageLoader.

I am awaiting more information from rustyshelf about his particular SSL configuration in Glassfish. I'm trying to reproduce the problem locally; maybe then we can pin down the exact circumstances in which this IE/SSL-related problem happens.

I figured out an easy workaround (well for us anyway)

Because we have Apache sitting in front of our Glassfish anyway, we just told apache to serve anything that is *.gif and *.png in the directory where our GWT project is deployed, and voila, the problem is no more.

I can't believe I didn't think of that earlier, but oh well, at least we have IE working now :)

This problem is happening because Internet Explorer requires that any content retrieved by the browser that is to be opened by a plugin must be cached. In this case, the ImageBundle .png file is opened by AlphaImageLoader, which qualifies as a plugin.

Both Tomcat and Glassfish will set the Pragma: No-cache and Cache-Control: no-cache HTTP Response headers whenever:

1) files are served up over SSL 2) the web application has a security constraint set on these files (URLs)

When IE sees these response headers, it obeys them and does not cache the content. The .png file is not cached, so it is not available to AlphaImageLoader. That is why the file does not display. This behavior is documented here (though this example has to do with MS Office files):

http://support.microsoft.com/?id=316431

Tomcat's behavior with SSL, security-constraints, caching headers, and the problem with IE is detailed here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=27122

Various fixes for the problem in Tomcat discussed. Two of the fixed which would work for Glassfish would be:

1) Add a servlet filter which explicitly sets the caching headers for .png files so that they are cached by the browser. This would almost be necessary anyway, because you want the server to tell the client that it can cache the generated image bundle <md5>.cache.png file permanently.

2) Add the following line to your sun-web-app declaration in sun-web.xml:

<property name="securePagesWithPragma" value="false" />

This setting is documented here:

http://docs-pdf.sun.com/819-3673/819-3673.pdf

Other alternatives would be:

1) Exclude the image bundle file from the security constraint

2) If there is sensitive data in any of the images in the image bundle, exclude that image from the bundle, and do #1

In summary, this is not a problem with GWT, so there is no code change that we can make to fix this problem. What we can do is add some javadoc to ImageBundle to inform developers about this problem, an add a note in the developer guide about this problem with IE which links over to the javadoc explaining the details.

Forgot to mention - securePagesWithPragma setting is documented on page 167 of http://docs-pdf.sun.com/819-3673/819-3673.pdf

Fix (doc changes) committed as r1200.

1.4 RC2 now released.