users@grizzly.java.net

Re: CometWriter assumes Transfer-Encoding: chunked

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Mon, 25 Jan 2010 13:53:43 +0100

Hi Richard,

can you pls. attach the code you're using to send Comet response?

Thank you.

WBR,
Alexey.

On Jan 22, 2010, at 2:49 , Richard Zschech wrote:

> Hi Alexey,
>
> If GlassFish decides to use "Connection: close" to signal the end of
> the HTTP response with the socket disconnecting rather than with
> chunks the CometWriter should not ouput the chunk length information.
>
> The example I have GlassFish responds with:
>
> HTTP/1.1 200 OK
> X-Powered-By: Servlet/3.0
> Server: GlassFish v3
> Cache-Control: no-cache
> Content-Type: text/plain;charset=UTF-8
> Date: Fri, 22 Jan 2010 01:33:39 GMT
> Connection: close
>
> 5
> ABCDE
> 0
>
> where I’ve written "ABCDE" to the CometWriter, 5 and 0 are the chunk
> lengths, but because the Transfer-Encoding is not chunked then the 5
> and 0 are interpreted as a part of the response data.
>
> It should be:
>
> HTTP/1.1 200 OK
> X-Powered-By: Servlet/3.0
> Server: GlassFish v3
> Cache-Control: no-cache
> Content-Type: text/plain;charset=UTF-8
> Date: Fri, 22 Jan 2010 01:33:39 GMT
> Connection: close
>
> ABCDE
>
>
>
> Another problem I’m having is the CometWriter assumes that you are
> only going to write one chunk to the HTTP response. It writes the 0
> length chunk to the response to terminate it. Can this be configured?
>
> From Richard.
>
>
> > Hi Richard,
> >
> > > CometWriter assumes that the HTTP response is using "Transfer-
> > > Encoding: chunked".
> > >
> > > In some cases Glassfish decides to respond with "Connection:
> close"
> > > where the user agent detects the end of the HTTP response from the
> > > connection closing rather than using HTTP keep alive and
> chunking .
> > Can you pls. elaborate? Not sure I understand why "Connection:
> close"
> > causes issue?
> >
> > Thank you.
> >
> > WBR,
> > Alexey.
>