tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Two way long running servlet connection problem
Date Sun, 21 Nov 2010 19:47:29 GMT
Caldarale, Charles R wrote:
>> From: André Warnier [] 
>> 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:
For additional commands, e-mail:

View raw message