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 ?

	ClippedImageImplIE6.java
	3.1 KB Download

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

(No comment was entered for this change.)

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

(No comment was entered for this change.)

Fix (doc changes) committed as r1200.

1.4 RC2 now released.