Thanks to John for your remarks. My reply is posted below.
Steve
----- Original Message -----
From: "John R Pierce" <pierce@hogranch.com>
To: <pgsql-general@postgresql.org>
Sent: Sunday, January 03, 2016 4:40 PM
Subject: Re: [GENERAL] Question -- Session Operations - Feasibility Of
Proposed Synchronization Method?
> On 1/3/2016 1:32 PM, Melvin Davidson wrote:
>> As others have pointed out, storing session data in a table is not a good
>> idea. Even if you use TRUNCATE, you will still not reclaim all the space
>> used unless you use vacuum full. More to the point, if you absolutely
>> must store session data, then why not just do it in a TEMPORARY table,
>> which will reside in memory and clean itself up when the session ends?
>
> The fundamental problem is that HTTP itself is stateless, and user
> sessions have to be enforced by the web app, with the aid of browser
> cookies. you can't simply directly link a http connection to a SQL
> connection and assume thats a session.
>
Please see my reply to Melvin Davidson.
The "session" I mean is the one that you point out, that has to be enforced
by the web app, to provide continuity missing from the stateless HTTP
protocol.
Except that I do not use browser cookies.
Instead of browser cookies, I use a parameter (session ID key) embedded in
the HTML page served by the app to the consumer's web browser.
And this parameter goes on a round-trip journey, back to the app
program that is launched by the HTTP server, when the visitor actions the
web page submit button and their browser sends an HTTP request message.
The format of the (32-character string) session ID key parameter is:
CCCCCCCCCC:YYYYMMDDHHMMSS:SSSSTT
where:
1. CCCCCCCCCC -- "quasi-unique" random session identification code
(10-char, hex-encoded), a hash value (e.g. substring of MD5) but NOT a hash
of a password to be remembered and reused, just a randomized value from
x0000000000 to xFFFFFFFFFF (decimal: 0 ... 1099511627775);
2. YYYYMMDDHHMMSS -- session initiation time (14-char, decimal-encoded) e.g.
20160105040427;
3. SSSS -- serial number of corresponding session context row when first
INSERTed (4-char, hex-encoded) value from x0001 to xFFFF (decimal: 1 ...
65535);
4. TT -- serial number of current session context table where session row is
stored (2-char, hex-encoded) value from x01 to x1F (decimal: 1 ... 31);
Here is a paste of example HTML:
<form method="post" action="./eto_session_act_2a.php"
enctype="multipart/form-data" accept-charset="ISO-8859-1">
<input type="hidden" name="a" value="B37000AC2C:20160105040427:0AD11A" />
<input type="hidden" name="d" value="BF46C6" />
<div id="centeredmenu">
<ul>
<li> <input type="submit" name="new_message_form_submit" value="New
Message Form" /> </li>
</ul>
</div>
...
</form>
In the above HTML, hidden field name="a"
value="B37000AC2C:20160105040427:0AD11A" is a session ID key input parameter
to PHP program eto_session_act_2a.php, that interprets parameter "a" as:
1. CCCCCCCCCC == "B37000AC2C";
2. YYYYMMDDHHMMSS == "20160105040427";
3. SSSS == "0AD1" (decimal 2769);
4. TT == "1A" (decimal 26);
> --
> john r pierce, recycling bits in santa cruz
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
