tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: two questions: HTTP 1.1 headers + constantly open connections in TC
Date Fri, 08 Aug 2008 15:19:41 GMT
Hash: SHA1


Albretch Mueller wrote:
| 1) Can you achieve such a thing as a registered, dedicated, always
| open connection to each client in a network from login to logout using
| tomcat?

Not really. HTTP is designed as a connectionless protocol. You might be
able to do this using the Comet Connector (about which I am completely

These days, everyone uses AJAX to make web applications appear to have
constantly-updating screens and things like that.

|  1.1)  How can browsers be configured to take advantage of them?

Server-push is an option, but is sucks. AJAX is your best bet IMO. Or,
use an entirely different protocol instead of HTTP (you could do this
using a Flash-based app or a Java applet).

|  1.2)  What would you suggest if I would like this configuration to be
| available to different browsers, the user may have?

Flash is much more available than Java for web browsers.

|  This would be beneficial if you want to use an internal, local
| network cache for a number of users you know in a network you own
| ~
|  Which each user's login a connection is open transparently to that
| user in a tomcat server that just works as a cache. Different users
| are not supposed to trample on each others' connections

What's wrong with a standard HTTP-based web application with requests
and responses?

|  2) In the (2004) article "Concerning Etags and Datestamps"
| [snip]
| The part I wouldn't totally agree with or that is not clear to me is
| "The first method involves an extra connection for each download,
| which takes time and server resources."
| I think when you hit a server with a "HEAD" request, the server just
| returns the meta-data without trying to setup sessions

Not necessarily. The server can do anything it wants to do. A HEAD
request is handled separately from the (possible) following GET request,
so if there are headers to be parsed and resources to check (such as the
size of a file, etc.), all that work will have to be done for the HEAD
request before anything can be sent back. That same work is likely to be
repeated when the GET request comes a moment later.

| or "keep-alive"
| connections from that client in an unencumbered way, but if you "GET"
| connections to server resources, servers will do the setup to estabish
| ongoing connections to that client, so then when you drop the
| connection after reading the headers, servers do keep the connection
| open wondering that went of with the client . . .

No, the server should see a dropped connection and just close and
cleanup the connection on the server side. It's true that a lot of work
might be needlessly done on the server side if the client just plans to
hand up the connection.

|  So, I think it you know that the server most likely didn't change
| some data and that the particular server reliably reports HTTP
| headers, then it is better to conditionally go with "HEAD" first
|  Is it true? Am I missing something?

I agree with the author that using If-Modified-Since and similar
strategies are the best bet because you are basically doing a HEAD + GET
with a single request. There are special response codes for the server
to use when the response should be "content has not been modified"
versus "content has been modified, and here it is".

Feel free to use HEAD followed by GET, but GET with predicates is
certainly going to be faster if the server correctly supports the
predicates themselves.

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message