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.