two questions: HTTP 1.1 headers + constantly open connections in TC

[Albretch Mueller-3]

~
 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?, and
~
 1.1)  How can browsers be configured to take advantage of them?
 1.2)  What would you suggest if I would like this configuration to be
available to different browsers, the user may have?
~
 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

~
 2) In the (2004) article "Concerning Etags and Datestamps"
~
 http://www.iwaw.net/04/Clausen.pdf
~
 by Lars R. Clausen, he states:
~
  "Avoiding download of the entire body can be done in three different ways: By
using a HEAD request first, and then GET if the content is predicted changed, by
using a GET and breaking connection after receiving the header if the content is
predicted unchanged, or by using the If-None-Match and If-Modified-Since headers
in the request. The first method involves an extra connection for each download,
which takes time and server resources. The second method requires low-level
interaction with the web client, which may be complex to implement. The third
method is preferable, though it is subject to errors if the web server does not
implement the required functionality correctly, and it may not be able
to support more
complex prediction schemes."
~
 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 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 . . .
~
 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?
~
 THanks
 lbrtchx

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christopher Schultz-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Albretch,

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
ignorant).

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkicZA0ACgkQ9CaO5/Lv0PBfvQCgh7CIJNXXy8echulIxOXqbsSL
i40AoJ7UxsEslVo+lFoBERtyVA8UcO3U
=IW8M
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ken Bowen]

I haven't stepped up to attempting Comet/NIO yet, but I have had
some small-scale success with a custom pseudo-push implementation
using the RPC in GWT (Google Web Toolkit); obviously we're using GWT  
for the pages.
When the browser starts, it uses rpc to ask for any available data:
    If data is ready, the server responds immediately, and then the  
browser asks again.
    If no data is available, the server implementation of the rpc  
executes wait() until
        the main server control executes notifyAll(), and the (newly  
available) data is returned
        to the browser,  which then asks again, etc.
Very conservative polling because of the wait/interrupt, but it ties  
up threads:  hence the "small scale".
This is ok for an application where the number of logged-in users is  
strictly controlled.
Since we will eventually scale up, I'll be trying out Comet sooner or  
later.

--Ken

On Aug 8, 2008, at 11:19 AM, Christopher Schultz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Albretch,
>
> 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
> ignorant).
>
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkicZA0ACgkQ9CaO5/Lv0PBfvQCgh7CIJNXXy8echulIxOXqbsSL
> i40AoJ7UxsEslVo+lFoBERtyVA8UcO3U
> =IW8M
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@...
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Albretch Mueller-3]

 OK, since I am trying to have java-based applications end-to-end and
since I own this network, I think I will use TC and Java Web Start
instead of applets
~
>>  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?
~
 I know the maximal number of clients that can be in this network and
TC can keep, say, 50 connections open, so I thought I would set up
these connections once users login or switch the box on, so that they
have access to their files through the JWS app from any of the boxes
they could use in the lab
~
 Thanks
 lbrtchx

On Fri, Aug 8, 2008 at 11:19 AM, Christopher Schultz
<chris@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Albretch,
>
> 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
> ignorant).
>
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkicZA0ACgkQ9CaO5/Lv0PBfvQCgh7CIJNXXy8echulIxOXqbsSL
> i40AoJ7UxsEslVo+lFoBERtyVA8UcO3U
> =IW8M
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@...
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...