Filip Hanik - Dev Lists wrote:
Unfortunately, it looks like it:
+for (int i=0; i+//this resets the remaining flag and the content
length on the filter
+//if we don't do this, then
request.getInputStream.read will return 0
+
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Actually, I think the server should be the one closing the
connection. In other cases, since it's a long running request,
discarding the connection is easier. In HTTP land, the server is
always the one in control of keepalive.
That's correct
Filip Hanik - Dev Lists wrote:
Actually, I think the server should be the one closing the connection.
In other cases, since it's a long running request, discarding the
connection is easier. In HTTP land, the server is always the one in
control of keepalive.
That's correct, however, the current
Remy Maucherat wrote:
Filip
Hanik - Dev Lists wrote:
Gents,
I have played around with the Comet implementation, fixed a few bugs
and got the initial it working, including async data from both client
and server.
I wanted to you get your input on moving forward with the follow
Filip Hanik - Dev Lists wrote:
Gents,
I have played around with the Comet implementation, fixed a few bugs and
got the initial it working, including async data from both client and
server.
I wanted to you get your input on moving forward with the following
features:
1. If CometServlet.read
Gents,
I have played around with the Comet implementation, fixed a few bugs
and got the initial it working, including async data from both client
and server.
I wanted to you get your input on moving forward with the following
features:
1. If CometServlet.read return false, the adapter should
