I'm cc'ing Simone, the developer that created png8 color quantization. Simone, I'm curious about how we create the palette for png8. Is it a set of 256 colors where each one has its own transparency, or do we specify a transparent pixel?

Oscar, I'm curious, did you ever manage to create a png8 that shows as transparent in IE? I'm trying to understand if it's possible to do something, of if any investigation would be wasted time (if IE6 is inherently unable to properly handle png with palette, I fear there is nothing we can do).

Yes, we get transparent background in IE6 when the image contains rendered elements.
The problem is when getting a totally empty PNG8 (no features within req'd bbox), in which case the image is opaque.

Huh, I was pretty sure that transparent pngs don't work at all in internet explorer. There are some javascript hacks you can do to make them work, but nothing you can do from the server side. See http://homepage.ntlworld.com/bobosola/ Why don't you just return gifs for your app? At least when it's ie6? That's what we do for all of our applications.

Chris, I belive this one is a little different. IE does not support full color, 24bit png, but I believe it supports paletted ones. It may that in the case of single transparent color the code that encodes the png does not properly set up the transparent pixel, or something like that.

We're getting a corrupt image.
Just as described in GEOS-423, but with PNG8.

Try to open this one with gimp (sf:streams layer, plain 1.6.2 install):
http://localhost:8080/geoserver/wms?WIDTH=256&SRS=EPSG%3A26713&LAYERS=sf%3Astreams&HEIGHT=256&STYLES=&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&BBOX=602319,4918546,603729,4919956&transparent=true

Ok, investigated a little, I can confirm it does not work. When the image is fully transparent (nothing has been drawn) the CustomPaletteBuilder class, responsible for the 24 -> 8 bits color reduction comes up with a palette with just one item.
This is correct, there is just one color, but unfortunately the png encoders do not work properly in this case, and they generate a grayscale png instead, which is not transparent.

The following patch workaround this by adding a fake second element to the generated palette so that it always at least two items. Seems to work, not sure if I'm curing the cause or just the symptom there, but at least the generated png is valid and transparent:

Index: C:/progetti/geoserver/src/trunkClean/geoserver/wms/src/main/java/org/vfny/geoserver/wms/responses/palette/CustomPaletteBuilder.java
===================================================================
--- C:/progetti/geoserver/src/trunkClean/geoserver/wms/src/main/java/org/vfny/geoserver/wms/responses/palette/CustomPaletteBuilder.java	(revision 8807)
+++ C:/progetti/geoserver/src/trunkClean/geoserver/wms/src/main/java/org/vfny/geoserver/wms/responses/palette/CustomPaletteBuilder.java	(working copy)
@@ -426,6 +426,10 @@
 		if (transparency == Transparency.BITMASK) {
 			size++; // we need place for transparent color;
 		}
+		// if the palette size happens to be just one (happens with a fully transparent image)
+		// then increase the size to two, otherwise the png encoders will go mad
+		if(size < 2)
+		    size = 2;
 
 		final byte[] red = new byte[size];
 		final byte[] green = new byte[size];

Simone, can you review it? To reproduce the issue with a GeoServer in standard configuration you can use the following wms request (got it from the map preview and adapted):

http://localhost:8080/geoserver/wms?WIDTH=256&LAYERS=sf%3Abugsites&STYLES=
&SRS=EPSG%3A26713&HEIGHT=256&FORMAT=image%2Fpng8&TILED=true&TILESORIGIN=589213.0189195721%2C4913481.836583115
&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap
&EXCEPTIONS=application%2Fvnd.ogc.se_inimage
&BBOX=599351.9645728546,4913481.836583115,601886.7009861752,4916016.572996436&transparent=true

Well, since I did not hear back from the palette builder's maintainer, I just went ahead and committed a change. Should be included in 1.6.4