OK, I now understand what is causing these exception and would like to suggest
a solution in Restlet.
The issue is in Restlet's ReadableChunkingChannel. In order to chunk an
existing representation, it needs to first decode it if it's encoded. In the
case of Encoding.DEFLATE, it would thus use an InflaterInputStream instance.
Unfortunately, there are two incompatible versions of the DEFLATE algorithm.
The default in the JVM is to use wrap mode, but you can explicitly set
nowrap mode like so:
new InflaterInputStream(stream, new Inflater(true))
Even more unfortunately, certain versions of Microsoft's Internet Explorer only
support the nowrap mode. So, you absolutely *must* set the nowrap flag if
you want to support IE when generating your own encoded Restlet representations.
So, what can Restlet do about this?
There can be two Encoding constants, one for each supported mode. The usual
DEFLATE, and perhaps DEFLATE_NOWRAP. In terms of outgoing HTTP headers, they
should be identical, but the Restlet stack should be able to maintain the
correct version of algorithm throughout, for example in
ReadableChunkingChannel. (It must also re-encode the chunk in the correct
version of the algorithm.)
A simpler solution may be to simply use nowrap always in Restlet. I've done
this in my pre-2.1 Restlet applications in order to support IE properly. But,
there are advantages to allowing developers some control over this.
A related side question: Is there be a way to avoid the decoding-re-encoding
done by ReadableChunkingChannel? Specifically, is there a way to send the
representation already chunked from the ServerResource?
-Tal
I'm getting these exceptions occasionally on a few specific resources, not
sure yet how to reproduce. Has anyone else seen them and have any information?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=3005128
