The DEFLATE issues: https://github.com/restlet/restlet-framework-java/issues/653 https://github.com/restlet/restlet-framework-java/issues/654
The decoding/encoding issue is trickier, and may require some discussion: https://github.com/restlet/restlet-framework-java/issues/655 I'm copy-pasting my suggested solution here, in case the mailing list would like to chime in with ideas: For chunking, it is necessary for the channel to decode the entity and re-encode the separate chunks. However, a much more optimal situation would be for this extra decoding/re-encoding not to occur. I can think of two possible solutions: 1. If Restlet knows that it will have to re-encode the entity, it should set the preferred Encoding to null for downstream, while storing a flag (request attribute?) telling it to encode on the way back. This way a ServerResource would know to provide an un-encoded entity and let ReadableChunkingChannel handle all the encoding. The advantage of this solution is that it's entirely transparent and would work for existing code. Unfortunately, if the ServerResource supports caching of any kind, it would not be able to cache encoded chunked representations. 2. It may be possible for ServerResource to detect that chunking is happening, in which case there may be a way to create a special kind of Representation (ChunkedRepresentation?) that encodes each chunks separately. The advantage of this solution is in the ability for caching optimization: the ServerResource would be able to cache ChunkedRepresentations according to chunk size and avoid unnecessary encoding. Ideally, Restlet would support both! However, I imagine that option #1 would be best as the default mode, with an API allowing a ServerResource to handle chunking via option #2. +++ I should note that as Prudence developer, I would strongly suggest that option #2 exist. Prudence does aggressive caching, and separately caches entities in all encoded variations, guaranteeing that encoding only ever happens once for cached entities. Unfortunately, option #1 would break this optimization and introduce encoding. (It's much worst at the moment, because Restlet will decode and re-encode.) ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3005684
