Ok, I'll take a shot
at this ...
In earlier versions
of the previous product (ahem ... a carry-over from the conference ... where we
weren't allowed to say the name of previous things, lest we be fined on behalf
of charity ... quite a way to get people to be generous, by the way, all
courtesy of Mr. BD)
Ok .. this will be
too confusing. Let me start again:
--------------------------------------------
In earlier versions
of Tango .. perhaps Version 3.0 ... 3.1 or thereabouts, I am quite sure that the
UserRef information could only be passed as a search (GET) argument (or through
a cookie, but let's leave that out) in order to qualify as the session
argument. In fact, we used to train people specifically with that
information, and demo to them what would happen otherwise.
Somewhere along the
way between version 3.0 and what is now Witango Version 4.0 (or Tango2000 SP1,
for that matter), the rules changed to permit the information to be passed using
either a POST or GET argument. It seemed to slip in, undocumented, or at
least, not well-documented. It is clear in all the examples, including
the Search and New Record builders, that the UserRef was (originally) to be
passed as a GET argument. I'm sure that the docs will be clarified with
Version 5.0.
Next, is the matter
of *why* it might be better one way or the other, even if both work. For
this, and this is my opinion only, and subject to clarification by my peers on
the list, there is a good reason to pass it as a GET argument. Here's
why:
The GET arguments
are passed in the HTTP header. The GET arguments are read by every router,
switch, firewall and proxy server that is between the server and the
client. Conversely, the body contents of each TCP/IP packet are not.
Imagine a
multi-server installation, where a user's variables are stored on only one of
the 3 or 4 servers which are sharing the load. It would seem reasonable
that if you want to invoke a session management system that requires a user to
be returned to a particular server for each successive new request originating
from that user, you'd best have an efficient method of doing that. You certainly
don't want to be fishing through the body of each TCP/IP packet looking for a
POST argument buried within. If you are the lead (proxy) server, with the
responsibility for disseminating the incoming requests, the greatest efficiency
would be if you did not need to look beyond the info in the HTTP header for the
discriminating information. Hence, for speed in a multi-server situation,
using a session management system as described above, the UserRef should be
passed in the header .. hands down, no contest.
And, of course, you
may not know when you start your masterpiece that you're going to grow it to a
multi-server installation. If and when it does, you certainly won't have
copious amounts of time to re-write your code at that point.
As Anthony pointed
out in another post, it might be better (or best) to define ways of storing
variables that are beyond local (or the new "request" ... vers. 5 feature) scope
in the database, thus allowing for Witango servers to be added or deleted from
the load group at will, without fear of losing a session. That would be
the subject of another POST. o[;-)
------------------------------
Now, there are
equally valid reasons why you might insist on the UserRef info being passed as a
POST argument. As above, the HTTP header is read by all devices along the
route of the TCP/IP packet. It must be, in order to properly route and
deliver the packet. Does that mean that if I copy someone else's UserRef
argument off of a currently valid session that I could "steal" their
session? You bet.
What's more, SSL
won't entirely help you, because SSL does not encrypt the header information,
only the body. (SSL can't encrypt the header, or the routers won't know where to
deliver the goods!) So, important information should be given
consideration as being passed as hidden POST args, and encrypted for good
measure.
Food for thought ...
and definitely not conclusive or the last word on this
matter.
But it is food for
thought, which is what we all need to be doing when laying out a
project.
Over and out on a
Friday afternoon .....
New Creation Consulting & Information Management Inc.
# 701, 889 West Pender Street, Vancouver, BC V6C 3B2 Canada
=====================================================
[EMAIL PROTECTED] http://www.ncol.com http://witango.ncol.com
Ph: (604) 576-3086 Fax: (604) 576-3025
