Caldarale, Charles R wrote:
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: Two way long running servlet connection problem
In HTTP 1.1, a change was made, with the objective of
avoiding the overhead of establishing/destroying a
connection for each request.
Careful here. The "connection" described above is the underlying TCP
connection, not the HTTP conversation.
The server reads an processes the request, and sends the response.
The client can now send a second request on the same connection.
The scenario the OP wants to discuss is not the simple request/response
situation, but more akin to a streaming mechanism, such as a file transfer -
but in this case, bidirectional. There's nothing in HTTP that prevents that,
as long as appropriate headers are generated so that both the request and
response do not have pre-established lengths.
Basically what I mean, is that there is not really a
provision in the webapp logic, for processing a second
request after it has sent a response to the current one.
Don't think of it as a second request, but rather as a continuation of the
existing one - again, similar to a file transfer over HTTP.
I am not saying that it is not possible, I am saying that this is not really "classic"
HTTP anymore.
You are probably thinking of chunked encoding, but in my view that is quite a different
thing : the kind of "conversation" going on there is no longer at the application level,
and it concerns purely "housekeeping" in terms of "here is another block of nnn bytes".
There is not really any "intelligent" conversation going on there.
To do what the OP seems to want, the client would have to send an "incomplete" request,
the webapp would have to start processing it despite the fact that it is incomplete; it
would have to send an incomplete response, to which the client would have to react by
sending another chunk of request, and so on. I just believe that this would be a lot of
trouble to achieve given the standard tools and APIs, and I wonder if the end justifies
the trouble.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
