On Dec 12, 2007 4:19 AM, Tuure Laurinolli <[EMAIL PROTECTED]> wrote: > Description of my encoder: > > ChunkedHttpResponseEncoder first expects an HttpResponse, and if the > HttpResponse has Transfer-encoding: chunked set, switches to expecting > HttpChunks instead. HttpChunks are simply containers for IoBuffers, and > are simply written to the Iosession, prefixed with the appropriate chunk > header. The response is terminated with a special END_TOKEN objec. When > the encoder receives an END_TOKEN, it switches back to expecting > HttpResponses. > > If the encoder receives an inappropriate object for its current state > (END_TOKEN or HttpChunk when expecting HttpResponse, or HttpResponse > when expecting HttpChunk or END_TOKEN, it throws an exception). > > Tuure Laurinolli >
I wrote several weeks ago an encoder, named HttpEncoder, that supports standard HTTP and chunked HTTP messages (among others :) ). It can handle ChunkedHttpMessage or HttpMessage classes. So when you send a HttpMessage then it just sends that message, if you send a ChunkedHttpMessage it uses ChunkedHttpMessage.isFirstChunk( ) to handle the chunked protocol correctly. The last chunk is not a token but an empty ChunkedHttpMessage (with a null body), and when HttpEncoder sends this empty last chunk it is as the HTTP specification says that the last chunked should be a zero body size chunk. It is the ChunkedHttpMessage that keeps its state, whether it's the first message or not, if the encoder would do this then I guess that you couldn't simultaneously send standard HTTP and chunked HTTP with the same encoder (when multiple sessions are using the same encoder), if you use different encoders then I guess you could send them simultaneously. Bogdan
