A few years ago a colleague of mine worked with Sun to implement pack200 HTTP Compression for our applet.  Now with the release of the Java 6 Plugin we have found a problem.  To use pack200 compression with our applets, we have a special servlet which is very similar to Sun's sample servlet.  In fact, in the Java 6 Pack200 and Compression Document (http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/pack200.html)  the sample servlet code shows our problem:

        String contentType = request.getContentType();

        ...

        // Pack200 Compression
        if (encoding != null && contentType != null &&
                contentType.compareTo(JAR_MIME_TYPE) == 0 &&
                encoding.toLowerCase().indexOf(PACK200_GZIP_ENCODING) > -1){

            contentEncoding = PACK200_GZIP_ENCODING;

We have included the contentType checks in our application (which is now commercial and very widely deployed) as Sun's example indicates, and it turns out that the Java 6 Plugin is no longer setting content-type= "application/x-java-archive" in the request header, and content-type is actually null and therefore our compressed jar.pack.gz files are not getting downloaded for use with the Java 6 Plugin.
 
The Java 6 plugin breaks this sample servlet and hence our servlet too